Discovered recently by Chris Coulson during code-audit of ntfs-3g -
actually had been fixed upstream late last year but no CVE assigned
Heap buffer overflow able to be triggered when mounting a filesystem
onto a mount point with path name greater than PATH_MAX, and from a
current working directory which has a path name also greater than
PATH_MAX
Contents of buffers is attacker controlled so heap can be overflown
with attacker controlled input - likely to leverage into arbitrary
code execution
Contrived example BUT in Debian and Ubuntu ntfs-3g is setuid root -
which then leads to root privilege escalation with arbitrary code
execution
Update was released within hours of the bug being made public to fix
the heap buffer overflow
Currently testing ntfs-3g as not-setuid root to release in a future
update to avoid any other possible privilege escalation bugs in the
future
Similar to previous CVE, forceput operator could be extracted from the
DefineResource method to allow access to the file-system outside of
the -dSAFER sandbox
superexec operator was available in the internal dictionary - also
able to be extracted and hence used to access files outside the
sandbox
Jann Horn reported the seccomp blacklist for TIOCSTI can be bypassed
snapd creates a seccomp filter for each snap which is designed to
block TIOCSTI (as this can be used to fake input to other processes
outside of the sandbox)
This is a 32-bit value to the ioctl system call, but on 64-bit
architectures the kernel does this comparison as a 64-bit integer - so
can be circumvented by using a 64-bit value to ioctl systemcall which
has other bits set in the upper 32 bits - since when seccomp does
comparison it uses the full 64 bits - so it won’t match the 32-bit
value of TIOCSTI and so will be allowed - but then when used as the
ioctl() argument it will correctly be truncated to 32-bits and the
ioctl will proceed
Fixed in snapd to add a second seccomp filter to disallow anything in
the upper 32-bits
Initially seemed like a kernel or libseccomp issue but both currently
document this as a limitation already so treated in the end as a
vulnerability in snapd