Re: [FD] Text injection on https://www.google.com/sorry/index via ?q parameter (no XSS)
Today at about 2025-02-13 19:00 I noticed the "≠" is back, but now the
type 0x12 payload of the ?q query parameter gets formatted into the
string representation of an IP address, rather than being copied almost
verbatim into the page. If the payload length is 4 bytes, it gets
formatted as an IPv4 address; if 16 bytes, as an IPv6 address. I didn't
try a ton of experiments, but it looks like payload lengths other than 4
and 16 cause the "≠" and payload not to appear at all.
./sorry-payload $'\x01\x02\x03\x04'
https://www.google.com/sorry/index?q=EgQBAgME
(archived) https://archive.is/rTNsC
IP address: ≠ 1.2.3.4
./sorry-payload ''
https://www.google.com/sorry/index?q=EhBBQUFBQUFBQUFBQUFBQUFB
(archived) https://archive.is/wcVi1
IP address: ≠
4141:4141:4141:4141:4141:4141:4141:4141
Special IPv6 address formats, such as the ::/96 prefix for
IPv4-compatible IPv6 addresses, have their special presentation
format; e.g. 0:0:0:0:0:0:0102:0304 becomes "::1.2.3.4", not "::102:304".
https://en.wikipedia.org/wiki/IPv6_address#Representation
printf
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x02\x03\x04' |
./sorry-payload
https://www.google.com/sorry/index?q=EhABAgME
(archived) https://archive.is/mCXsX
IP address: ≠ ::1.2.3.4
Whatever purpose the "≠" is supposed to serve, representing the
right-hand side as a string is probably what was originally intended,
rather than just blasting the bytes of the IP address into the HTML.
On Wed, Jan 29, 2025 at 07:15:28PM -0700, David Fifield wrote:
> I tested a few more times, and it appears the text injection has
> disappeared.
>
> These are timestamps when I tested, with offsets relative to the initial
> discovery.
>
> +0h 2025-01-28 03:00initial discovery
> +5h 2025-01-28 08:19?q=EgtoZWxsbyB3b3JsZA works
> (https://archive.is/DD9xB)
> +14h 2025-01-28 17:31?q=EgtoZWxsbyB3b3JsZA works
> (no archive)
> +45h 2025-01-30 00:18?q=EgtoZWxsbyB3b3JsZA doesn't work
> (https://archive.is/0PJRW)
>
> On Tue, Jan 28, 2025 at 02:26:16AM -0700, David Fifield wrote:
> > The page https://www.google.com/sorry/index is familiar to Tor and VPN
> > users. It is the one that says "Our systems have detected unusual
> > traffic from your computer network. Please try your request again
> > later." You will frequently be redirected to this page when using Tor
> > Browser, when you do a search on a Google site such as www.youtube.com
> > or scholar.google.com. The text of the page reports the client IP
> > address, a timestamp of the request, and the URL that was requested.
> >
> > At 2025-01-28 03:00 or earlier, the "sorry" page changed its behavior
> > from what I have seen before. After the client IP address, the page now
> > displays " ≠ ", followed by a few apparently nonsense bytes (not even
> > necessarily properly UTF-8–encoded). The extra bytes turn out to come
> > from a data structure that is encoded in the ?q URL query parameter. By
> > changing the ?q parameter, you can make the string of bytes have any
> > length and contents you like. The byte string will be included in the
> > HTML body, after the client IP address and " ≠ ". However, any bytes
> > that have meaning in HTML will be HTML-escaped, so while you can make
> > text appear on the page, no XSS is possible, as far as I can tell.
> >
> > This is a simple demonstration:
> >
> > https://www.google.com/sorry/index?q=EgtoZWxsbyB3b3JsZA
> > (archived) https://archive.is/DD9xB
> >
> > This displays:
> >
> > IP address: ≠ hello world
> >
> > Let's decode the ?q payload to see what's going on.
> >
> > $ python3 -c 'import base64;
> > print(repr(base64.urlsafe_b64decode("EgtoZWxsbyB3b3JsZA==")))'
> > b'\x12\x0bhello world'
> >
> > After base64 decoding, the first byte is 0x12, which is some kind of
> > data type indicator. The second byte, 0x0b, is the length of the value
> > to follow. Then the value is what ends up being copied into the page.
> >
> > The length field is actually a Protobuf varint. Lengths greater than 127
> > need to be encoded as more than 1 byte:
> > https://protobuf.dev/programming-guides/encoding/#varints
> > The following is a Python program to encode arbitrary byte strings
> > appropriately for the ?q parameter:
> >
> > #!/usr/bin/env python3
> > import base64
> > import sys
> > if len(sys.argv) > 1:
> > payload, = sys.argv[1:]
> > payload = payload.encode()
> > else:
> > payload = sys.stdin.buffer.read()
> > def encode_varint(n):
> > e = [n & 0x7f]
> > n >>= 7
> > while n > 0:
> > e[len(e) - 1] |= 0x80
> > e.append(n & 0x7f)
> > n >>= 7
> > return bytes(e)
> > print(base64.urlsafe_b64encode(b"\x12" + encode_varint(len(payload)) +
> > payload).rstrip(b"=").decod
[FD] Netgear Router Administrative Web Interface Lacks Transport Encryption By Default
___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
[FD] Monero 18.3.4 zero-day DoS vulnerability has been dropped publicly on social network.
Hello, About an hour ago, a group appearing to be named WyRCV2 posted a note on the nostr social network, which can be found at the following link: https://primal.net/e/note1vzh0mj9rcxax9cgcdapupyxeehjprd68gd9kk9wrv939m8knulrs4780x7 >Monero Zero-day vulnerability and exploit > >Take down the XMR network with us, make the future a better a place. Save, share, use. > >https:[//]anonpaste.org/?cccb7639afbd0650#HaMQAfzFdCqMDh9MwNuGRGUBXLgtk5yHWdAzS7MbvEVN The paste link includes a list of nodes that the attacker has instructed to target, along with a Python code to leverage the attack. According to their explanation, this vulnerability is expected to be patched in the next release of Monero. Any Monero node that exposes its RPC port is vulnerable to memory exhaustion. I can confirm that the Python code works and using it against a test node leads to a crash due to memory exhaustion. The code is extremely simple, as it spams requests without attempting to read responses, causing Monero to keep them indefinitely in memory until a crash occurs. The attackers claim to have taken down 8 public nodes and 1 seed node, which is used as a rendezvous point for new nodes to connect to the network. ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
[FD] [CVE-2024-54756] GZDoom <= 4.13.1 Arbitrary Code Execution via Malicious ZScript
In GZDoom 4.13.1 and below, there is a vulnerability involving array sizes in ZScript, the game engine's primary scripting language. It is possible to dynamically allocate an array of 1073741823 dwords, permitting access to the rest of the heap from the start of the array and causing a second array declared in the same function to overlap with this huge array. The result is an exploit chain that allows arbitrary code execution through a malicious ZScript file, embedded in a WAD or PK3 file that can be distributed among the Doom community as a mod, mapset, etc. MITRE has reserved CVE-2024-54756 for this. This vulnerability affects GZDoom 4.13.1 and earlier, and most likely LZDoom is also affected. The devs have been notified privately, and it should be patched in 4.13.2 onward. This vulnerability was announced in the ZDoom Discord chatroom, but to the best of my knowledge nowhere else publicly. I've already posted a writeup and proof of concept for Linux on GitHub: https://github.com/Chainmanner/GZDoom-Arbitrary-Code-Execution-via-ZScript-PoC Nevertheless, in the interest of preservation through duplication, the writeup in Markdown format (README.md) is attached to this email, and also attached are the PoC's zscript.zs and MAPINFO files. To summarize the vulnerability and what it can lead to: * In a ZScript function, one can allocate an array of 1073741823 or more 32-bit integers. Normally the contents of an array should be initialized, but for some reason they are not for arrays this large. Every element of this array, from the start of the array to the end of the heap, can be read and written. * If a second array of reasonable size is allocated after the unreasonably huge array, both arrays will overlap. Particularly useful if the second array contains object pointers, as those cannot be arbitrarily set; by being able to modify those pointers directly, that gives the attacker an arbitrary read/write primitive to anywhere in addressable memory. * An arbitrary execute primitive is possible by including a function pointer in the object pointed to in the second overlapping array and modifying it directly. * ZScript can sometimes be JIT-compiled for performance improvements, and Asmjit is used to accomplish this. Unfortunately, it's misconfigured in a way that causes three RWX memory maps to be present, meaning an attacker can just write shellcode to one of them and execute it if they can find one such page. * ZScript code is presumed to be JIT-compiled deterministically and in-order. Therefore, an attacker can defeat ASLR and locate any of the RWX pages by identifying the offsets of ZScript functions within any such pages and scanning the heap for pointers having such offsets (plus filtering for plausible addresses above, say, 0x6000). The longer the list of such pointers, the more likely an RWX page will be found. The exploit is thus: * Create an array of 1073741823 32-bit integers. * Find an RWX region's address by scanning the heap from the huge array's start, and comparing each 64-bit integer's non-random bits with those in the known ZScript function offset list, while also rejecting addresses under e.g. 0x6000. * Allocate a second array of two object pointers: one being the arbitrary read/write primitive, the second being the arbitrary execute. * Prepare the arbitrary execute primitive to point to where the shellcode will be. * Write the shellcode and any necessary data to the RWX region. * Execute the shellcode. The code is all executed in a static event handler called when the engine starts, before the main menu is reached. A few other things I should note follow. I unfortunately didn't study GZDoom's source code enough to fully understand why this huge array vulnerability happens; however, based on some informal testing, I have strong reason to believe it's due to an integer overflow, specifically an unsigned integer being treated as signed. I support this theory with the following: * 1073741823 * 4 (the size of a 32-bit int) = 4294967292 = 0xfffc = -4 when considered signed * Arrays are supposed to be initialized to all-zeros. * No crash occurs when the array contains 1073741823 integers, but if the array has 536870912 ints, a crash occurs - namely a segmentation fault that occurs _before_ the start of the heap. This is pure speculation, though. I should have spent the time to properly understand how this vulnerability came about so that I could suggest a proper fix, but I got too excited finding a way to chain the bug into an arbitrary code execution that I didn't. I'll do it better the next time I find and officially report a vulnerability. The PoC I created isn't very reliable. It doesn't have many ZScript function offsets and I filter out pointers under 0x5600, not under 0x6000 as I suggest above. One may have to correct that and run the exploit several times for it to work. Still, given that it does work w
