| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
|
On boot, the Pillar eve container checks for the existence and content of
“/config/GlobalConfig/global.json”.
If the file exists, it overrides the existing configuration on the device on boot.
This allows an attacker to change the system’s configuration, which also includes some
debug functions.
This could be used to unlock the ssh with custom “authorized_keys” via the
“debug.enable.ssh” key, similar to the “authorized_keys” finding that was noted before.
Other usages include unlocking the usb to enable the keyboard via the “debug.enable.usb”
key, allowing VNC access via the “app.allow.vnc” key, and more.
An attacker could easily enable these debug functionalities without triggering the “measured
boot” mechanism implemented by EVE OS, and without marking the device as “UUD”
(“Unknown Update Detected”).
This is because the “/config” partition is not protected by “measured boot”, it is mutable and it
is not encrypted in any way.
An attacker can gain full control over the device without changing the PCR values, thereby not
triggering the “measured boot” mechanism, and having full access to the vault.
Note:
This issue was partially fixed in these commits (after disclosure to Zededa), where the config
partition measurement was added to PCR13:
• aa3501d6c57206ced222c33aea15a9169d629141
• 5fef4d92e75838cc78010edaed5247dfbdae1889.
This issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot. |
|
On boot, the Pillar eve container checks for the existence and content of
“/config/authorized_keys”.
If the file is present, and contains a supported public key, the container will go on to open
port 22 and enable sshd with the given keys as the authorized keys for root login.
An attacker could easily add their own keys and gain full control over the system without
triggering the “measured boot” mechanism implemented by EVE OS, and without marking
the device as “UUD” (“Unknown Update Detected”).
This is because the “/config” partition is not protected by “measured boot”, it is mutable, and
it is not encrypted in any way.
An attacker can gain full control over the device without changing the PCR values, thus not
triggering the “measured boot” mechanism, and having full access to the vault.
Note:
This issue was partially fixed in these commits (after disclosure to Zededa), where the config
partition measurement was added to PCR13:
• aa3501d6c57206ced222c33aea15a9169d629141
• 5fef4d92e75838cc78010edaed5247dfbdae1889.
This issue was made viable in version 9.0.0 when the calculation was moved to PCR14 but it was not included in the measured boot. |
| PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but
due to the change that was implemented in commit
“7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the
problem of the config partition not being measured correctly.
Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of
SHA256.
This issue was somewhat mitigated due to all of the PCR extend functions
updating both the values of SHA256 and SHA1 for a given PCR ID.
However, due to the change that was implemented in commit
“7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no longer the case for PCR14, as
the code in “measurefs.go” explicitly updates only the SHA256 instance of PCR14, which
means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the “vault”
key, changes to the config partition would still not be measured.
An attacker could modify the config partition without triggering the measured boot, this could
result in the attacker gaining full control over the device with full access to the contents of the
encrypted “vault”
|
| Link following in Zoom Rooms for macOS before version 5.16.0 may allow an authenticated user to conduct an escalation of privilege via local access.
|
|
When TACACS+ audit forwarding is configured on BIG-IP or BIG-IQ system, sharedsecret is logged in plaintext in the audit log. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| Deserialization of Untrusted Data in emlog pro v.2.1.15 and earlier allows a remote attacker to execute arbitrary code via the cache.php component. |
| Deyue Remote Vehicle Management System v1.1 was discovered to contain a deserialization vulnerability. |
| A deserialization vulnerability in Afterlogic Aurora Files v9.7.3 allows attackers to execute arbitrary code via supplying a crafted .sabredav file. |
| A symbolic link following vulnerability in Buildkite Elastic CI for AWS versions prior to 6.7.1 and 5.22.5 allows the buildkite-agent user to change ownership of arbitrary directories via the PIPELINE_PATH variable in the fix-buildkite-agent-builds-permissions script. |
| Redisson is a Java Redis client that uses the Netty framework. Prior to version 3.22.0, some of the messages received from the Redis server contain Java objects that the client deserializes without further validation. Attackers that manage to trick clients into communicating with a malicious server can include especially crafted objects in its responses that, once deserialized by the client, force it to execute arbitrary code. This can be abused to take control of the machine the client is running in. Version 3.22.0 contains a patch for this issue.
Some post-fix advice is available. Do NOT use `Kryo5Codec` as deserialization codec, as it is still vulnerable to arbitrary object deserialization due to the `setRegistrationRequired(false)` call. On the contrary, `KryoCodec` is safe to use. The fix applied to `SerializationCodec` only consists of adding an optional allowlist of class names, even though making this behavior the default is recommended. When instantiating `SerializationCodec` please use the `SerializationCodec(ClassLoader classLoader, Set<String> allowedClasses)` constructor to restrict the allowed classes for deserialization. |
| Improper input validation vulnerability in ChooserActivity prior to SMR Nov-2023 Release 1 allows local attackers to read arbitrary files with system privilege. |
| Jenkins Pipeline Maven Integration Plugin 1330.v18e473854496 and earlier does not properly mask (i.e., replace with asterisks) usernames of credentials specified in custom Maven settings in Pipeline build logs if "Treat username as secret" is checked. |
| The webserver utilizes basic authentication for its user login to the configuration interface. As encryption is disabled on port 80, it enables potential eavesdropping on user traffic, making it possible to intercept their credentials. |
| The user management section of the web application permits the creation of user accounts with excessively weak passwords, including single-character passwords. |
| Inappropriate file type control in Zscaler Proxy versions 3.6.1.25 and prior allows local attackers to bypass file download/upload restrictions. |
| An exposure of sensitive information to an unauthorized actor [CWE-200] in FortiSIEM version 7.0.0 and before 6.7.5 may allow an attacker with access to windows agent logs to obtain the windows agent password via searching through the logs. |
| Chunghwa Telecom NOKIA G-040W-Q has a vulnerability of weak password requirements. A remote attacker with regular user privilege can easily infer the administrator password from system information after logging system, resulting in admin access and performing arbitrary system operations or disrupt service. |
| knplabs/knp-snappy is a PHP library allowing thumbnail, snapshot or PDF generation from a url or a html page.
## Issue
On March 17th the vulnerability CVE-2023-28115 was disclosed, allowing an attacker to gain remote code execution through PHAR deserialization. Version 1.4.2 added a check `if (\strpos($filename, 'phar://') === 0)` in the `prepareOutput` function to resolve this CVE, however if the user is able to control the second parameter of the `generateFromHtml()` function of Snappy, it will then be passed as the `$filename` parameter in the `prepareOutput()` function. In the original vulnerability, a file name with a `phar://` wrapper could be sent to the `fileExists()` function, equivalent to the `file_exists()` PHP function. This allowed users to trigger a deserialization on arbitrary PHAR files. To fix this issue, the string is now passed to the `strpos()` function and if it starts with `phar://`, an exception is raised. However, PHP wrappers being case insensitive, this patch can be bypassed using `PHAR://` instead of `phar://`. A successful exploitation of this vulnerability allows executing arbitrary code and accessing the underlying filesystem. The attacker must be able to upload a file and the server must be running a PHP version prior to 8. This issue has been addressed in commit `d3b742d61a` which has been included in version 1.4.3. Users are advised to upgrade. Users unable to upgrade should ensure that only trusted users may submit data to the `AbstractGenerator->generate(...)` function.
|
| Screenshot vulnerability in the input module. Successful exploitation of this vulnerability may affect confidentiality. |
| An issue was discovered in Plixer Scrutinizer before 19.3.1. It exposes debug logs to unauthenticated users at the /debug/ URL path. With knowledge of valid IP addresses and source types, an unauthenticated attacker can download debug logs containing application-related information. |
