* spender@... <spender@...> [2004-07-30 06:35:57 -0400]: > Actually there's a new glibc package that fixes the bug with vsyscall. > http://gotom.jp/~gotom/debian/glibc/2.3.2.ds1-14/ ... and it is available officialy now, changelog snipshet: - debian/patches/glibc232-remove-vsyscall.dpatch: Remove __ASSUME_VSYSCALL to fix the system startup failure on the machine using PAX. (Closes: #245563) Cheers, Laszlo/GCS
Laszlo 'GCS' Boszormenyi wrote: >* spender@... <spender@...> [2004-07-30 06:35:57 -0400]: > > > >>Actually there's a new glibc package that fixes the bug with vsyscall. >>http://gotom.jp/~gotom/debian/glibc/2.3.2.ds1-14/ >> >> > ... and it is available officialy now, changelog snipshet: > - debian/patches/glibc232-remove-vsyscall.dpatch: Remove > __ASSUME_VSYSCALL > to fix the system startup failure on the machine using PAX. > (Closes: #245563) > > > This version of glibc might not make it into Sarge (base frozen). But then there is an RC bug against libc, so it is still possible. - Adam -- -- Building your applications one byte at a time http://www.galacticasoftware.com
Hi all, /proc/net seems to be sometimes fifo, sometimes unix socket: [root <at> viper:~:13:35:51:604] $ ls -ld /proc/net srwxrwxrwx 4 mysql mysql 0 Aug 3 13:35 /proc/net [root <at> viper:~:13:35:51:605] $ ls -ld /proc/net prw------- 4 root root 0 Aug 3 13:35 /proc/net [root <at> viper:~:13:35:52:606] $ ls -ld /proc/net srwxrwxrwx 4 mysql mysql 0 Aug 3 13:35 /proc/net [root <at> viper:~:13:35:52:607] $ ls -ld /proc/net prw------- 4 root root 0 Aug 3 13:35 /proc/net [root <at> viper:~:13:35:53:608] $ ls -ld /proc/net srwxrwxrwx 4 mysql mysql 0 Aug 3 13:35 /proc/net [root <at> viper:~:13:35:53:609] $ ls -ld /proc/net srwxrwxrwx 4 root root 0 Aug 3 13:35 /proc/net [root <at> viper:~:13:35:53:610] $ ls -ld /proc/net prw------- 4 root root 0 Aug 3 13:35 /proc/net [root <at> viper:~:13:35:54:611] $ But if I do ls -l /proc|grep net, I become always(Continue reading)
Hi, just noticed new kernel exploit on BUGTRAQ (http://isec.pl/vulnerabilities/isec-0016-procleaks.txt) As far as I can understand that thing is very difficult to fix in every possible place; does GrSecurity make it more difficult to exploit? Best Wishes, Viktors
Doesn't look like we are immune. I don't run mtrr by default thankfully, so at least it won't work with the script kiddies on our shell servers out of the box.. Here's what we got: admin <at> seyonne:~$ uname -a Linux seyonne 2.4.26-grsec #11 Sat Aug 7 00:13:52 MDT 2004 i686 unknown unknown GNU/Linux admin <at> seyonne:~$ ls -alh UPGRADE_KIT.TGZ -rw-(Continue reading)r--r-- 1 admin users 60M Jun 10 23:06 UPGRADE_KIT.TGZ admin <at> seyonne:~$ ./mtrr-x UPGRADE_KIT.TGZ [+] mmaped uncached file at 0x40157000 - 0x43c90000 [+] mmaped kernel data file at 0x43c90000 [+] Race won! [+] READ 137 bytes in 1381654 usec [+] SUCCESS, lseek fails, reading kernel mem... PAGE 25 [+] done, err=Bad address dmesg shows nothing: *SNIP* reiserfs: found format "3.6" with standard journal reiserfs: using ordered data mode reiserfs: checking transaction log (device sd(8,3)) ... for (sd(8,3)) sd(8,3):Using r5 hash to sort names
On Wed, 4 Aug 2004, Viktors Rotanovs wrote: > just noticed new kernel exploit on BUGTRAQ > (http://isec.pl/vulnerabilities/isec-0016-procleaks.txt) > As far as I can understand that thing is very difficult to fix in every > possible place; does GrSecurity make it more difficult to exploit? No, as far as I can see. Al Viro already created patch fixing it here and there ... http://linux.bkbits.net:8080/linux-2.4/gnupatch <at> 411064f7uz3rKDb73dEb4vCqbjEIdw -- -- JiKos.
grsecurity 2.0.1 has been released for Linux 2.4.27 and 2.6.7. gradm has been updated to 2.0.1 for this release. This release includes PaX updates, proper locking that resolves NULL pointer oopses that some were experiencing, role de-authentication no longer requires a password, role name and subject name are displayed with every log if the RBAC system is enabled, the random TCP source ports feature won't fail before all ports are used, IP-based role support has been added to special roles, capability inheritance is fixed, the regular expression matching code for RBAC objects has been enhanced to support expected results of filename matching better and also handles [a-Z] style matching, stack usage has been reduced, kernel memory usage has been reduced, domain support has been added which allows you to group separate user roles together in the RBAC system, fixed XFS sleep-on-locking errors in 2.6, and automatic exploit bruteforcing deterrence, which delays an attack in services like apache where a parent forks off several children all sharing the same randomized address space layout and the attacker attempts to bruteforce the children by exhausting every possible randomized address. This release also fixes an important security issue discovered by stealth which allowed an attacker to kill protected processes in the RBAC system through a system call added recently to Linux. The chroot restrictions were unaffected by the addition of the system call. Some naming conventions were also changed, so /etc/grsec/acl has become /etc/grsec/policy. gradm will automatically move the file for you. gradm also supports directory including again, and several bugs have been fixed. If you're going to use 2.6.7, please also apply fixes for the numerous security bugs present in that kernel. Due to significant changes in the "stable" 2.6 tree that break much of PaX, a 2.6.8 patch may not be coming soon.(Continue reading)
* spender@... <spender@...> [040808 13:51]: > If you're going to use 2.6.7, please also apply fixes for the numerous > security bugs present in that kernel. Due to significant changes in the > "stable" 2.6 tree that break much of PaX, a 2.6.8 patch may not be > coming soon. Does anyone have a list of links to patches for these security bugs? P.s Great job Brad! -- -- Erik Månsson \ 'But it'll kill him!' 'It could have been us.' 'It could have been worse.' (Colour of Magic) 'What?'
* Erik M?nsson <goodbyte@...> [2004-08-08 14:43:21 +0200]: > Does anyone have a list of links to patches for these security bugs? As someone already mentioned a pre-work of the fixes: http://linux.bkbits.net:8080/linux-2.4/gnupatch <at> 411064f7uz3rKDb73dEb4vCqbjEIdw Cheers, Laszlo/GCS
lm-sensors `sensors -s` fails with "Can't access procfs/sysfs for writing" on any kernel that's has grsec in it even when it's grsec disabled. I can't really confirm much on this subject but Tim Yamin (who is not subscribed here) would know more on the subject. Here is the related Gentoo bug # and it includes a patch. Could you please review this spender and advise if said patch is the right way to handle things. http://bugs.gentoo.org/show_bug.cgi?id=59708 http://bugs.gentoo.org/attachment.cgi?id=37032&action=view Thanks. -- -- Ned Ludd <solar@...> Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer
_______________________________________________ grsecurity mailing list grsecurity@... http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
RSS Feed2 | |
|---|---|
1 | |
2 | |
1 | |
1 | |
3 | |
1 | |
1 | |
5 | |
3 | |
2 | |
6 | |
1 | |
1 | |
7 | |
5 | |
4 | |
1 | |
4 | |
5 | |
16 | |
8 | |
1 | |
15 | |
7 | |
8 | |
15 | |
15 | |
2 | |
1 | |
2 | |
2 | |
9 | |
7 | |
3 | |
10 | |
9 | |
8 | |
27 | |
4 | |
5 | |
5 | |
5 | |
4 | |
20 | |
1 | |
1 | |
21 | |
8 | |
3 | |
10 | |
28 | |
18 | |
20 | |
6 | |
8 | |
4 | |
15 | |
50 | |
14 | |
28 | |
31 | |
33 | |
43 | |
24 | |
53 | |
50 | |
19 | |
91 | |
47 | |
52 | |
55 | |
43 | |
39 | |
62 | |
24 | |
8 |
