From f08d10b0b571ee2494d75a6527719e95814f8383 Mon Sep 17 00:00:00 2001 From: "advisory-database[bot]" <45398580+advisory-database[bot]@users.noreply.github.com> Date: Thu, 24 Apr 2025 17:00:32 +0000 Subject: [PATCH] Publish Advisories GHSA-2jh5-g5ch-43q5 GHSA-vqfr-h8mv-ghfj --- .../2025/04/GHSA-2jh5-g5ch-43q5/GHSA-2jh5-g5ch-43q5.json | 6 ++++-- .../2025/04/GHSA-vqfr-h8mv-ghfj/GHSA-vqfr-h8mv-ghfj.json | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/advisories/github-reviewed/2025/04/GHSA-2jh5-g5ch-43q5/GHSA-2jh5-g5ch-43q5.json b/advisories/github-reviewed/2025/04/GHSA-2jh5-g5ch-43q5/GHSA-2jh5-g5ch-43q5.json index 9a5c5a17530..2a3676bab45 100644 --- a/advisories/github-reviewed/2025/04/GHSA-2jh5-g5ch-43q5/GHSA-2jh5-g5ch-43q5.json +++ b/advisories/github-reviewed/2025/04/GHSA-2jh5-g5ch-43q5/GHSA-2jh5-g5ch-43q5.json @@ -1,9 +1,11 @@ { "schema_version": "1.4.0", "id": "GHSA-2jh5-g5ch-43q5", - "modified": "2025-04-23T22:25:20Z", + "modified": "2025-04-24T16:59:12Z", "published": "2025-04-23T22:25:20Z", - "aliases": [], + "aliases": [ + "CVE-2025-43858" + ], "summary": "YoutubeDLSharp allows command injection on windows system due to non sanitized arguments", "details": "## Summary\nThis vulnerability only apply when running on a Windows OS.\nAn unsafe conversion of arguments allows the injection of a malicous commands when starting `yt-dlp` from a commands prompt.\n\n> [!CAUTION]\n> **NOTE THAT DEPENDING ON THE CONTEXT AND WHERE THE LIBRARY IS USED, THIS MAY HAVE MORE SEVERE CONSEQUENCES. FOR EXAMPLE, A USER USING THE LIBRARY LOCALLY IS A LOT LESS VULNERABLE THAN AN ASP.NET APPLICATION ACCEPTING INPUTS FROM A NETWORK/INTERNET.**\n\n## Details\n\nThe vulnerability have been implemented in a commit (https://github.com/Bluegrams/YoutubeDLSharp/commit/fdf3256da18d0e2da4a2f33ad4a1b72ff8273a50) 3 year ago to fix a issue with unicode characters on Windows. ( In the latest version at the time of writing this, the code seems to have moved here : https://github.com/Bluegrams/YoutubeDLSharp/blob/b2f7968a2ef06a9c7b2c212785cfeac0b187b6d8/YoutubeDLSharp/YoutubeDLProcess.cs#L87 )\nIn this commit, a new way of starting yt-dlp was implemented, method that was defined as the default behaviour. \n\nWhen the internal method [`ConvertToArgs`](https://github.com/Bluegrams/YoutubeDLSharp/commit/fdf3256da18d0e2da4a2f33ad4a1b72ff8273a50#diff-8ec44b4ade6ce6ed38ebf7e765dc86c426984a18304cd1cd320bf92500133c88R64) get called, the application will test multiples conditions to decide on how the yt-dlp application should be started. The condition we are interesed in, as well a the default one on Windows, is at [line 99](https://github.com/Bluegrams/YoutubeDLSharp/commit/fdf3256da18d0e2da4a2f33ad4a1b72ff8273a50#diff-8ec44b4ade6ce6ed38ebf7e765dc86c426984a18304cd1cd320bf92500133c88R99) . Inside the `if` statement, we can see that insead of directly calling the `yt-dlp` binary, a command prompt is opened to run `yt-dlp`. \n\n**The problem arises when you realize that both arguments in the `ConvertToArgs` method may be provided by an untrusted client.** Since the documentation of YoutubeDLSharp does not warn developers about this behavior, they might assume that the library handles this safely by ensuring that the arguments are secure to run inside a command prompt. Instead, the two potentially malicious arguments are directly appended to the command string without any sanitization (see line [104](https://github.com/Bluegrams/YoutubeDLSharp/commit/fdf3256da18d0e2da4a2f33ad4a1b72ff8273a50#diff-8ec44b4ade6ce6ed38ebf7e765dc86c426984a18304cd1cd320bf92500133c88R104) and [107](https://github.com/Bluegrams/YoutubeDLSharp/commit/fdf3256da18d0e2da4a2f33ad4a1b72ff8273a50#diff-8ec44b4ade6ce6ed38ebf7e765dc86c426984a18304cd1cd320bf92500133c88R107)).\n\n\n\n## PoC\nFor this example, I'm going to use the version `1.1.1` and a method inside [YoutubeDL.cs](https://github.com/Bluegrams/YoutubeDLSharp/blob/b2f7968a2ef06a9c7b2c212785cfeac0b187b6d8/YoutubeDLSharp/YoutubeDL.cs). Assuming you are running on a Windows OS, this method will by default use a CMD to open yt-dlp.\n\n```c#\nusing YoutubeDLSharp;\n\npublic async Task> GetMediaInformation()\n{\n YoutubeDL youtubeDl = new YoutubeDL();\n\t// Fetch media information using a badly crafted \"url\" (escaped)\n\treturn await youtubeDl.RunVideoDataFetch(\"https://example.com/\\\" & start calc.exe\");\n}\n```\nAt the call of `GetMediaInformation`, the method `RunVideoDataFetch` will be called, internally this method will call the vulnerable method [`ConvertToArgs`] resulting in the following string: \n```\n/C chcp 65001 >nul 2>&1 && \"yt-dlp.exe\" --external-downloader \"m3u8:native\" --external-downloader-args \"ffmpeg:-nostats -loglevel 0\" -o \"C:\\Users\\\\Documents\\GitHub\\\\\\bin\\Release\\net8.0\\%(title)s [%(id)s]_%(epoch)s.%(ext)s\" --force-overwrites --no-part -i --ignore-config --ffmpeg-location \"ffmpeg.exe\" --exec \"echo outfile: {}\" -- \"https://example.com/\" & start calc.exe\"\n```\n>[!NOTE]\n> Some text have been replaced by `` inside the command.\n\nThe important part here is at the end of the command, we can see `\"https://example.com/\" & start calc.exe\"`, if we compare it with our \nmalicious URL `https://example.com/\" & start calc.exe`, we can see that the method added quotes at the start and the end of the string. However, our additional quote in the URL followed by the `&` character made it so the CMD interprets what follows the `&` as a new command, thus executing `yt-dlp` **AND** the *very* dangerous `start calc.exe` 😊.\n\nHere is a screenshot of the processes using another malicious url `https://example.com/\" & start msinfo32`\n![showcase](https://github.com/user-attachments/assets/d6f5513c-a69b-4cdd-9820-3f4d71b5c457)\n\n## Impact\nEvery users running a effected version on a Windows OS with the [`UseWindowsEncodingWorkaround`](https://github.com/Bluegrams/YoutubeDLSharp/commit/fdf3256da18d0e2da4a2f33ad4a1b72ff8273a50#diff-8ec44b4ade6ce6ed38ebf7e765dc86c426984a18304cd1cd320bf92500133c88R44) value defined to true (default behaviour). If you are using build-in methods form the [YoutubeDL.cs](https://github.com/Bluegrams/YoutubeDLSharp/blob/b2f7968a2ef06a9c7b2c212785cfeac0b187b6d8/YoutubeDLSharp/YoutubeDL.cs) file, the value is `true` by default and **you cannot disable it from theses methods**.\n\n## Patch\n\nUpgrade to **v.1.1.2 or higher** of YoutubeDLSharp. The `UseWindowsEncodingWorkaround` property has been removed entirely in v.1.1.2.\n\n## Workaround\n(only for v1.1.1 or lower, please upgrade to the latest version)\n\n### Using `YoutubeDLProcess`\nIf you are using a `YoutubeDLProcess` object directly to communicate with yt-dlp, you can disable `UseWindowsEncodingWorkaround` to mitigate the vulnerability. Doing so will execute the yt-dlp binary directly. However, you will lose support for Unicode characters.\n**Example:**\n```c#\nYoutubeDLProcess youtubeDLProc = new YoutubeDLProcess()\n{\n UseWindowsEncodingWorkaround = false\n};\n```\n\n### Sanitizing url\nIf you want to keep support for Unicode characters or are using methods from the [YoutubeDL.cs](https://github.com/Bluegrams/YoutubeDLSharp/blob/b2f7968a2ef06a9c7b2c212785cfeac0b187b6d8/YoutubeDLSharp/YoutubeDL.cs) file, you would need to manually sanitize your inputs until a version with a fix is released. For URL sanitization, I managed to prevent the exploitation of the PoC by creating this method. However, I can't guarantee it would work in every case.\n```c#\n\t\tpublic static string? SanitizeUrl(string url)\n\t\t{\n\t\t\t// Parse the URL using Uri\n\t\t\tif (Uri.TryCreate(url, UriKind.Absolute, out Uri? urlUri))\n\t\t\t{\n\t\t\t\t// According to the microsoft docs getting the absolute url append\n\t\t\t\t// all of the others fields, theses fields get URI escaped when you GET them\n\t\t\t\t// (https://learn.microsoft.com/en-us/dotnet/api/system.uri.query?view=net-8.0#remarks) \n\t\t\t\treturn urlUri.AbsoluteUri;\n\t\t\t}\n\t\t\t// Invalid url format\n\t\t\treturn null;\n\t\t}\n```\nThis works because Uri properties have special characters like spaces and `\"` escaped into percent numbers like `%20`, thus turning our malicous url into `https://example.com/%22%20&%20start%20calc.exe`.\n**Note, however, that if you modify the options with which yt-dlp is run, you need to ensure every option is also sanitized (assuming they are taken from a untrusted user input). This method won't work as these options are not URLs.**", "severity": [ diff --git a/advisories/github-reviewed/2025/04/GHSA-vqfr-h8mv-ghfj/GHSA-vqfr-h8mv-ghfj.json b/advisories/github-reviewed/2025/04/GHSA-vqfr-h8mv-ghfj/GHSA-vqfr-h8mv-ghfj.json index d2e25c38fa1..ed7ddd78942 100644 --- a/advisories/github-reviewed/2025/04/GHSA-vqfr-h8mv-ghfj/GHSA-vqfr-h8mv-ghfj.json +++ b/advisories/github-reviewed/2025/04/GHSA-vqfr-h8mv-ghfj/GHSA-vqfr-h8mv-ghfj.json @@ -1,9 +1,11 @@ { "schema_version": "1.4.0", "id": "GHSA-vqfr-h8mv-ghfj", - "modified": "2025-04-24T16:07:56Z", + "modified": "2025-04-24T16:59:21Z", "published": "2025-04-24T16:07:56Z", - "aliases": [], + "aliases": [ + "CVE-2025-43859" + ], "summary": "h11 accepts some malformed Chunked-Encoding bodies", "details": "### Impact\n\nA leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions.\n\n### Details\n\nHTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of \"chunks\", each of which consists of:\n\n- chunk length\n- `\\r\\n`\n- `length` bytes of content\n- `\\r\\n`\n\nIn versions of h11 up to 0.14.0, h11 instead parsed them as:\n\n- chunk length\n- `\\r\\n`\n- `length` bytes of content\n- any two bytes\n\ni.e. it did not validate that the trailing `\\r\\n` bytes were correct, and if you put 2 bytes of garbage there it would be accepted, instead of correctly rejecting the body as malformed.\n\nBy itself this is harmless. However, suppose you have a proxy or reverse-proxy that tries to analyze HTTP requests, and your proxy has a _different_ bug in parsing Chunked-Encoding, acting as if the format is:\n\n- chunk length\n- `\\r\\n`\n- `length` bytes of content\n- more bytes of content, as many as it takes until you find a `\\r\\n`\n\nFor example, [pound](https://github.com/graygnuorg/pound/pull/43) had this bug -- it can happen if an implementer uses a generic \"read until end of line\" helper to consumes the trailing `\\r\\n`.\n\nIn this case, h11 and your proxy may both accept the same stream of bytes, but interpret them differently. For example, consider the following HTTP request(s) (assume all line breaks are `\\r\\n`):\n\n```\nGET /one HTTP/1.1\nHost: localhost\nTransfer-Encoding: chunked\n\n5\nAAAAAXX2\n45\n0\n\nGET /two HTTP/1.1\nHost: localhost\nTransfer-Encoding: chunked\n\n0\n```\n\nHere h11 will interpret it as two requests, one with body `AAAAA45` and one with an empty body, while our hypothetical buggy proxy will interpret it as a single request, with body `AAAAXX20\\r\\n\\r\\nGET /two ...`. And any time two HTTP processors both accept the same string of bytes but interpret them differently, you have the conditions for a \"request smuggling\" attack. For example, if `/two` is a dangerous endpoint and the job of the reverse proxy is to stop requests from getting there, then an attacker could use a bytestream like the above to circumvent this protection.\n\nEven worse, if our buggy reverse proxy receives two requests from different users:\n\n```\nGET /one HTTP/1.1\nHost: localhost\nTransfer-Encoding: chunked\n\n5\nAAAAAXX999\n0\n```\n\n```\nGET /two HTTP/1.1\nHost: localhost\nCookie: SESSION_KEY=abcdef...\n```\n\n...it will consider the first request to be complete and valid, and send both on to the h11-based web server over the same socket. The server will then see the two concatenated requests, and interpret them as _one_ request to `/one` whose body includes `/two`'s session key, potentially allowing one user to steal another's credentials.\n\n### Patches\n\nFixed in h11 0.15.0.\n\n### Workarounds\n\nSince exploitation requires the combination of buggy h11 with a buggy (reverse) proxy, fixing either component is sufficient to mitigate this issue.\n\n### Credits\n\nReported by Jeppe Bonde Weikop on 2025-01-09.", "severity": [