grsecurity-1.99cvs with parisc-linux-2.4.20pa22 patch
hello debian-hppa,
finally Brad and i got the grsecurity thing on my parisc box going...
my test machine, a nice little 712 gecko, called "mickey" is currently
running a freshly compiled 2.4.20-pa22-grsec...
here is the patch:
https://nikita.ath.cx/users/pappy/grsec/199_cvs_pappy/linux2420pa22-grsec199cvs-patch.txt
http may work too.
after fixing some problems with defines and such, i succeeded patching and compiling a 2.4.20-pa22 from ftp.parisc-linux.org.
as we can see, the stack protection stuff via PaX is almost fully defined to be left out on an architecture like parisc...
i am currently testing 3 different fields of interest:
--- network probing via nmap and other attacks
...
nikita:~# nmap -O -v 192.168.1.98
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Remote operating system guess: Linux Kernel 2.4.0 - 2.4.17 (X86)
Uptime 0.005 days (since Sat Jan 25 19:07:37 2003)
TCP Sequence Prediction: Class=random positive increments
Difficulty=4171911 (Good luck!)
IPID Sequence Generation: All zeros
...
stingray:~/nmap-3.10ALPHA9# ./nmap -O -v 192.168.1.98
Starting nmap V. 3.10ALPHA9 ( www.insecure.org/nmap/ )
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20
Uptime 0.011 days (since Sat Jan 25 19:06:02 2003)
TCP Sequence Prediction: Class=random positive increments
Difficulty=1986275 (Good luck!)
IPID Sequence Generation: All zeros
--- setting up and hardening local filesystem ACL`s and program contexts
plus chroots, which is imho totally platform independent
...
gradm -E worked fine, syslogging is working, some default protections like
/etc/grsec already in place, keep going
...
eth0: link ok.
grsec: From 192.168.1.99: Loaded grsecurity 1.9.9
grsec: From 192.168.1.99: denied access to hidden file /etc/grsec by (gradm:247) UID(0) EUID(0), parent (bash:195) UID(0) EUID(0)
grsec: From 192.168.1.99: denied mkdir of /etc/grsec by (mkdir:248) UID(0) EUID(0), parent (bash:195) UID(0) EUID(0)
grsec: From 192.168.1.99: denied access to hidden file /etc/grsec by (mkdir:248) UID(0) EUID(0), parent (bash:195) UID(0) EUID(0)
grsec: From 192.168.1.99: denied access to hidden file /etc/grsec by (bash:195) UID(0) EUID(0), parent (sshd:192) UID(0) EUID(0)
grsec: From 192.168.1.99: denied access to hidden file /etc/grsec by (bash:195) UID(0) EUID(0), parent (sshd:192) UID(0) EUID(0)
grsec: From 192.168.1.99: denied access to hidden file /etc/grsec by (bash:195) UID(0) EUID(0), parent (sshd:192) UID(0) EUID(0)
grsec: From 192.168.1.2: denied connect to the unix domain socket /dev/log by (in.ftpd:252) UID(0) EUID(0), parent (inetd:145) UID(0) EUID(0)
grsec: From 192.168.1.2: denied connect to the unix domain socket /dev/log by (in.ftpd:252) UID(0) EUID(0), parent (inetd:145) UID(0) EUID(0)
grsec: From 192.168.1.2: denied open of /var/log/ksymoops/20030125.log for appending by (modprobe:255) UID(0) EUID(0), parent (exim:251) UID(0) EUID(0)
grsec: From 192.168.1.2: denied open of /var/log/ksymoops/20030125.log for appending by (modprobe:255) UID(0) EUID(0), parent (exim:251) UID(0) EUID(0)
grsec: From 192.168.1.2: denied connect to the unix domain socket /dev/log by (modprobe:255) UID(0) EUID(0), parent (exim:251) UID(0) EUID(0)
grsec: From 192.168.1.2: denied connect to the unix domain socket /dev/log by (modprobe:255) UID(0) EUID(0), parent (exim:251) UID(0) EUID(0)
...
--- trying to dig further into the stack protection settings and try to get into that later
...
there is documentation available on exploiting GR31 and other registers that for example hold return addresses for functions in parisc.
altogether with these examples it should be possible to test and develop a solution based on these vulnerabilities of the parisc system.
...
bye, Alex
--
pub 1024/05E1A80C 2001/12/16 Alexander Gabert (http://nikita.ath.cx) <pappy@nikita.ath.cx>
Key fingerprint = 2D 84 B0 CB F5 67 8A 22 8D 37 6E 6B 8A 3B 7F D6 05 E1 A8 0C
Reply to: