Linux kernel issues

How or does any know if Astaro's current nix kernel is vulnerable? The following link discuss's this. Debians site was attacked recently.
http://isc.sans.org/diary.php?storyid=1482

As I understand the exploit, it has to be run from the console or via ssh sessions. I don't think you let everybody login to your astaro box?!

No, I am the only one who can log into my console,etc. Thanks for reply. After I posted question, I read more about it. It would be a local escalation.

Critical: 
Less critical 
Impact: Security Bypass
Privilege escalation
 
Where: Local system
 
Solution Status: Vendor Patch 

 
OS: Linux Kernel 2.6.x

 
 Select a product and view a complete list of all Patched/Unpatched Secunia advisories affecting it. 

 
CVE reference: CVE-2006-2451
 

 
Description:
A vulnerability has been reported in the Linux Kernel, which can be exploited by malicious, local users to bypass certain security restrictions or potentially gain escalated privileges.

The vulnerability is caused due to improper handling of core dumps. This can be exploited to dump core files into usually restricted directories or potentially gain root privileges.

Local exploit or not (with the right remote access a local exploit becomes a local exploit) it'll be good to know whether or not Astaro is affected.

Considering that the kernel version reported by Astaro is 2.6.10-51-smp on my 6.300 machine, I doubt it is affected by this particular vulnerability as the bug was introduced in 2.6.13 (though it could have inadvertantly been backported!).

Drees, I do agree with what you say. According to Securityfocus site,2.6.10 kernel is vulnerable. Although it doesn't say if Suse 2.6 kernel is specifically.
quotes

Debian also confirmed that this exploit was used on their recently compromised machine 

rPath Security Advisory: 2006-0122-1
Published: 2006-07-07
Products: rPath Linux 1
Rating: Major
Exposure Level Classification:
Local Deterministic Denial of Service
Updated Versions:
kernel=/conary.rpath.com@rpl[:D]evel//1/2.6.16.24-0.1-1

References:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2451
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2934
https://issues.rpath.com/browse/RPL-488

Description:
Previous versions of the kernel package are vulnerable to two denial
of service attacks. The first allows any local user to fill up file
systems by causing core dumps to write to directories to which they
do not have write access permissions. The second applies only to
systems using the SCTP protocol, which is not enabled by default,
and the tools required to configure it (lksctp-tools) are not included
in rPath Linux. This vulnerability, which cannot apply to systems
without lksctp-tools installed, enables a remote denial of service
attack in which specially-crafted packets can crash the system.


This vulnerability enables an attacker to get elevated privileges on a local machine. There have been several exploits released and we can confirm that they work. We've tested this on unpatched SuSE and RedHat Enterprise Linux machines:

$ ./a.out

prctl() suidsafe exploit

(C) Julien TINNES

[+] Installed signal handler
[+] We are suidsafe dumpable!
[+] Malicious string forged
[+] Segfaulting child
[+] Waiting for exploit to succeed (~28 seconds)
[+] getting root shell
sh-3.00#


also,http://www.securityfocus.com/bid/18874/info does show 2.6.10. 

I would assume the remote utilities are not on Astaro. But the actual knowing of this is curriousity to me. There is alot of links and some os that have this. I would think Astaro would know best of there kernel. It does say remote no go,but.

why don t astro ubgrade to new kernel? [:@] Astaro is firewall and we don t need security kernel "bug" in FIREWALL if "patch/new kerenl" can fix this.

Will astaro ubgrade kernel, and when?

My guess is that updating the kernel on this sort of system isn't as easy as one would think. There has to be a lot of testing involved. I would guess we will see one the next major release.

I do think it is important to keep kernel resonably up to date, basicly with in a couple versions of the most current. If you are running absolutely current there will be issues that will come up that people have not expereinced which will make it more difficult to troubleshoot. Plus you need to make sure that all of your apps running on the firewall support the new kernel.

6.301 updates the kernel compared to 6.300, but there is no mention of any kernel vulnerability fixes besides a PASV FTP fix.

why don t astro ubgrade to new kernel? [:@] Astaro is firewall and we don t need security kernel "bug" in FIREWALL if "patch/new kerenl" can fix this.

Will astaro ubgrade kernel, and when?

It's not as easy as you might believe - Astaro 6.x relies on SuSE Linux Enterprise Server 9.0 aka SLES 9. Simply employing another kernel might have unprecedible effects, several libs and init-scripts might not run anymore etc... Therefore, I'm afraid, Astaro has just to wait until SuSE fixes the kernel bug so they (Astaro) can build their own kernel.

As far as I have seen till now, the Astaro kernel doesn't differ from the SLES-Kernel. Please tell me if I'm wrong.

However, I agree with you that it would be a good idea to have a hardened kernel running, like GRE or Owl, which have some nice features implemented (tramplin protection, buffer overflow protection ...)

Have a nice day

why don t astro ubgrade to new kernel? [:@] Astaro is firewall and we don t need security kernel "bug" in FIREWALL if "patch/new kerenl" can fix this.

Will astaro ubgrade kernel, and when?

It's not as easy as you might believe - Astaro 6.x relies on SuSE Linux Enterprise Server 9.0 aka SLES 9. Simply employing another kernel might have unprecedible effects, several libs and init-scripts might not run anymore etc... Therefore, I'm afraid, Astaro has just to wait until SuSE fixes the kernel bug so they (Astaro) can build their own kernel.

As far as I have seen till now, the Astaro kernel doesn't differ from the SLES-Kernel. Please tell me if I'm wrong.

However, I agree with you that it would be a good idea to have a hardened kernel running, like GRE or Owl, which have some nice features implemented (tramplin protection, buffer overflow protection ...)

Have a nice day

One other thing to consider... often being on the "bleeding edge" of things like kernel updates, and other binaries, runs the risk of unstable code.. I'd prefer the proven executables remain, and patched as necessary.. a local exploit like this, well, they'd have to already be lurking around in the Astaro to utilize it.. so I prefer that the patches are tested longer before application.. .just my .02 .... I just keep thinking about how many "patches" I've applied to Micro$oft, Oracle, and yes, even open source products have resulted in something else being broken.

I am not sure why you think the Astaro version of the OS is not hardend? When I originally applied I asked a few naive questions at the time and was advised they use a hardend linux OS.

The new version appears to run faster than the previous version.

Ian M

Hi there all, 

it is a common policy of nearly all linux distributions to not upgrade the major kernel version of a stable release, but backport security fixes if needed.
Changing the major kernel version (like 2.6.10 to 2.6.16 for example) can bring unpredictable compatibility issus.

Just to give you an impression, Astaro is testing their major kernel upgrades, which are done during major version upgrades of ASG, for more than three months internally, before going to beta's.

Astaro always maintain's a security patched kernel for all stable releases, backporting known security fixes to the maintained version either from SuSE or other sources.
Our goal is to always deliver the best and most secure security solution.

regards
Gert