CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

[joneall]

Should we be worried about this?

http://isc.incidents.org/diary.html?storyid=9574

I'm running Lucid vmlinuz-2.6.32-24-generic-pae 32-bit.

Btw, Wikipedia tells me pae is to address memory beyond 4GB. I have exactly 4GB. So why pae? Or is it always installed?

[Vistaus]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

"beyond" is wrong. 4 GB and higher should be stated. That's why you have the PAE-kernel.

[Yuri sss]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

Should we be worried about this?

http://isc.incidents.org/diary.html?storyid=9574

I'm running Lucid vmlinuz-2.6.32-24-generic-pae 32-bit.

Btw, Wikipedia tells me pae is to address memory beyond 4GB. I have exactly 4GB. So why pae? Or is it always installed?

Wikipedia is wrong there (it's not always the most reliable source, as anyone can edit it - even clueless people).
32-bit can only handle 3GB. The pae kernel adds the ability to move that 3GB window with lots of swapping.
You should install the 64-bit version (the upcoming Maverick next month is a good occasion for that). Then you can make the best use of your 4 GB and don't need to worry about that security hole anymore. More info below.

Re: 32 bit vs 64 bit?
« Reply #9 on: September 07, 2010, 06:11:56 am »

Right now I'm running the 32bit 10.04.

The computer it's running on is a Dell Vostro 1500, with a Intel Dual core 2, 4GB RAM, and 256MB Nvidia 8500 Geforce video card.

Once 10.10 comes out, I plan to wipe it and install the new release.

Should I keep it at 32 bit, or upgrade to 64 bit?

If you want to make full use of your 4GB Ram, then you *must* use 64-bit.
Due to its architecture, it's *impossible* for 32-bit to use more than 3GB of Ram.
Another limitation of 32-bit is that no application can use more than 2GB of Ram, which brakes out applications using lots of memory, e.g. video processing, dvd ripping, image processing of large files, modern 3D applications etc.

The 32-bit pae kernel is only an ugly hack. It of course can't address more than 3GB of Ram - all it does is doing lots of swapping in and swapping out to access the remaining memory. The result of this is increased hard disk activity because of all the sawpping, causing more wear and tear for the hard disks (and more noise if you have noisy ones). Also, there's of course a performance degradation - while the OS is busy with the swapping, all other processes have to stand back and are only executed at a reduced speed.

I switched to 64bit with Jaunty. All in all, I see about a 15% performance boost, +- 5%.

I have been strictly 64bit since coming to kubuntu - the main reason I switched - and have had no 32 issues. I even play an old Loki games using 32 bit libs.

I also rip dvd's often and my experience is about the same as wizards - roughly 2 hrs using 32 bit PCLinuxos and 8-16 minutes with kubuntu.

My machine specs are in my sig - q6600 oc's and 8 gb ram

There you have it, just what I said.

[joneall]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

If I understand then, 64bit does not require a special CPU, but depends only on the RAM. Right?

For info, my cpu, according to /proc/cpuinfo, is a Pentium(R) Dual-Core CPU E5400 @ 2.70GHz/ Will that do for the 64-bit version?

Somebody already recommended I install the 64-bit version, but I understood it took more than just what I have. Maybe the video card?

Thanks in advance.Pentium(R) Dual-Core CPU E5400 @ 2.70GHz

[GreyGeek]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

Should we be worried about this?
.....

NO, it doesn't affect the 32bit Linux OS and isn't a threat to Ubuntu or Kubuntu. I explain why here.

[Vistaus]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

"If I understand then, 64bit does not require a special CPU, but depends only on the RAM. Right?"

Nope, wrong. It DOES require a special CPU. Well, if you buy a new computer (except for netbooks) then you already have that "special" CPU. But older computers mostly don't have a CPU that is capable of 64-bit, and netbooks don't have that one either.

[GreyGeek]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

....
For info, my cpu, according to /proc/cpuinfo, is a Pentium(R) Dual-Core CPU E5400 @ 2.70GHz/ Will that do for the 64-bit version?
.....

Your CPU is 64bit because it is Dual Core. The performance of your computer will increase by about 15% using the 64bit kernel.

You can check which Linux kernel you are using by opening a Konsole and issuing
uname -a

uname -a
Linux sonyvgnfw140e 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64 GNU/Linux

As you can see, I am using the 6 bit kernel (x86_64).

[zlow]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

....
For info, my cpu, according to /proc/cpuinfo, is a Pentium(R) Dual-Core CPU E5400 @ 2.70GHz/ Will that do for the 64-bit version?
.....

Your CPU is 64bit because it is Dual Core. The performance of your computer will increase by about 15% using the 64bit kernel.

You can check which Linux kernel you are using by opening a Konsole and issuing
uname -a

uname -a
Linux sonyvgnfw140e 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64 GNU/Linux

As you can see, I am using the 6 bit kernel (x86_64).

That's not entirely true. Some of the original dual core CPUs were not 64bit enabled. You can find out if you have 64bit capability by looking for the lm flag in a 'cat /proc/cpuinfo'.

[GreyGeek]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

zlow, you are correct.

I knew the second I posted that, that some one would disagree., but I was too lazy to change it because it is essentially true for most laptops today and because the 32 bit dual core had such a short life

The Intel Yonah had two cores but the CPU microcode was 32 bit. As wikipedia pointed out:

On July 27, 2006, Intel's Core 2 processors were released. By Q2 2007, Intel expected 90% of its laptop CPU production to be converted to the heavily-revised Intel Core 2 processors. The original Intel Core (Yonah) product had an unusually short lifespan as a stepping stone to the 64-bit Intel Core 2.

Or, like my 6 year old Gateway m675prr laptop which, although it had only one CPU, used hyper-threading to mimic two CPUs. That really didn't make it faster. The Linux system monitor's "system load - CPU history" graph would show two lines as if there were actually two CPU's when, in fact, there was only one. It confused the threads with separate CPUs. So, two CPU lines doesn't mean that one is running a dual core machine, either. The 64 bit Linux OS would reject the install it when I attempted to try it out on that Gateway, as it would on all 32 bit dual cores.

[zlow]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

zlow, you are correct.

I knew the second I posted that, that some one would disagree., but I was too lazy to change it because it is essentially true for most laptops today and because the 32 bit dual core had such a short life

The Intel Yonah had two cores but the CPU microcode was 32 bit. As wikipedia pointed out:

I agree that the 32bit Core Duo was short lived, unfortunately I have a Yonah chip in one of my older computers. Even the dual core Atom chips are 64bit enabled these days.

http://www.intel.com/products/proces...ifications.htm

Or, like my 6 year old Gateway m675prr laptop which, although it had only one CPU, used hyper-threading to mimic two CPUs. That really didn't make it faster. The Linux system monitor's "system load - CPU history" graph would show two lines as if there were actually two CPU's when, in fact, there was only one. It confused the threads with separate CPUs. So, two CPU lines doesn't mean that one is running a dual core machine, either. The 64 bit Linux OS would reject the install it when I attempted to try it out on that Gateway, as it would on all 32 bit dual cores.

Hyperthreading provided some value in that it allowed the schedular to divide time slices better between threads or processes. It allowed a system to stay somewhat responsive if a single threaded process chewed up an entire CPU.

That said, I haven't ever found it beneficial, and in some cases (older versions of VMWare Server) it caused software to effectively run slower when enabled.

[zlow]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

Should we be worried about this?

http://isc.incidents.org/diary.html?storyid=9574

I'm running Lucid vmlinuz-2.6.32-24-generic-pae 32-bit.

Btw, Wikipedia tells me pae is to address memory beyond 4GB. I have exactly 4GB. So why pae? Or is it always installed?

The only time to be concerned over this is if you are running a 64bit kernel, and either allowed access to users via ssh (IE: web hosting, or to a friend), or you had the computer directly connected to the internet without any router or firewall and had exposed services with known vulnerabilities (like phpmyadmin for example).

In that case, you should run rkhunter to check for a root kit. If you had none of those things, and you have installed the patch released the other day you are probably fine.

The issue with this exploit is that it installed a root kit leaving a backdoor on the system *if* an attacker was able to get into the system to exploit the kernel somehow.

The bigger issue isn't that the exploit was just released, the issue is that the exploit was underground for ~2 years before being made public.

[GreyGeek]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

It was noticed and fixed in 2007, but a recursion commit in 2008 reopened it. So, it could have been "underground" for the last two years, i.e., someone before Hawkes discovered it and had been using it, but I doubt it. Your favorite Ukrainian supported hacker website didn't know about it. IF it had been open for the last two years then professional and state supported hackers wasted a eight months of MANUAL "dear john" attacks just to compromise 700 Linux boxes. That a 700 zombie Linux bot farm is the largest ever found is evidence that no significant Linux back door exploit is operating in the wild. During that same 8 months a 1,300,000 Windows zombie bot farm was discovered.

Also, approximately 70% of the Internet servers are running Apache (presumably on Linux or BSD) and only 20% are running Windows. IF this exploit were in the wild it would have been reported by the more responsible server admins. For the 47,292,193 servers sampled in that survey 33 million were exposed to this exploit but for such a large number NO reports of Linux internet servers being compromised by this exploit have been reported. IF such an infection had taken place several anti-Linux forces would have made sure it reached the front pages of all major media, and get repeated endlessly for months or years afterwords.

And, being a local exploit, most single account Linux users have nothing to worry about if, like you say, they haven't purchased a domain name for the Apache server running on their box, and put it online, or they don't allow remote logins or remote desktop accesses, which are turned off by default in Kubuntu.

If folks think their box may have been exploited they can download a tool from KSplice here, which will report the backdoor, if it exists on the user's system.

[zlow]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

It was noticed and fixed in 2007, but a recursion commit in 2008 reopened it. So, it could have been "underground" for the last two years, i.e., someone before Hawkes discovered it and had been using it, but I doubt it.

It is implied in the "other" exploit that the "other" exploit was underground for 2 years.

Thanks you for signing-off on this one guys.

This exploit has been tested very thoroughly
over the course of the past few years on many many targets.

Thanks to redhat for being nice enough to backport it into early
kernel versions (anything from later August 2008+)

Ac1dB1tch3z would like to say ... YOU Ben Hawkes. You are a new hero! You saved the
plan8 man. Just a bit too l8.

Exploit attached. Another 0day bites the dust and goes into our public exploit pack
Ac1dB1tch3z brings you ABftw.c - Linux Kernel x86_64 local not0dayanymore exploit.

Source: http://seclists.org/fulldisclosure/2010/Sep/268

Your favorite Ukrainian supported hacker website didn't know about it.

As I have said multiple times, that site isn't the malware underground. If it was, you wouldn't be able to google it. Underground sites are not available over the general access internets, it usually takes an invite and some sort of encrypted connection.

IF it had been open for the last two years then professional and state supported hackers wasted a eight months of MANUAL "dear john" attacks just to compromise 700 Linux boxes. That a 700 zombie Linux bot farm is the largest ever found is evidence that no significant Linux back door exploit is operating in the wild. During that same 8 months a 1,300,000 Windows zombie bot farm was discovered.

This is not true. You cannot make the connection that the person with the recently published exploit hangs out with the person that attempted to create this botnet.

Also, approximately 70% of the Internet servers are running Apache (presumably on Linux or BSD) and only 20% are running Windows. IF this exploit were in the wild it would have been reported by the more responsible server admins. For the 47,292,193 servers sampled in that survey 33 million were exposed to this exploit but for such a large number NO reports of Linux internet servers being compromised by this exploit have been reported. IF such an infection had taken place several anti-Linux forces would have made sure it reached the front pages of all major media, and get repeated endlessly for months or years afterwords.

Again, a kernel exploit that requires a shell cannot be attacked through another service with no vulnerability. That's why I said phpmyadmin and not Apache. Apache has a very good security track record, where PHPMyAdmin does not.

Example: http://saifulfaizan.blogspot.com/201...e-exploit.html

And, being a local exploit, most single account Linux users have nothing to worry about if, like you say, they haven't purchased a domain name for the Apache server running on their box, and put it online, or they don't allow remote logins or remote desktop accesses, which are turned off by default in Kubuntu.

They don't have to have a "domain name", you can reach a computer over the internet by IP alone. Try it yourself by browsing to http://74.125.45.105/ (google). Apache is one of 10,000 (or more) possible applications for the Linux platform that expose one or more ports. My implication was that one of these must be installed, be directly connected to the internet (no not behind a home use router), and contain a known vulnerability that grants someone exploiting it a local user shell. I used PHPMyAdmin because it has a history of problems like this, as does Joomla and other similar apps.

If folks think their box may have been exploited they can download a tool from KSplice here, which will report the backdoor, if it exists on the user's system.

This is sane advice. If you are directly connected to the internet, running services or behind a router and forwarding ports to your computer (you may not even know if you are using upnp), it may be in your interest to run rkhunter or the ksplice diagnostics tool (which is based on the exploit source code). If you are just a single user that uses his PC to surf the web and check email, you most likely have nothing to worry about.

[Yuri sss]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

"If I understand then, 64bit does not require a special CPU, but depends only on the RAM. Right?"

Nope, wrong. It DOES require a special CPU. Well, if you buy a new computer (except for netbooks) then you already have that "special" CPU. But older computers mostly don't have a CPU that is capable of 64-bit, and netbooks don't have that one either.

Actually, only very old computers with old single-core Cpus don't support 64-bit, as it was already introduced in 2003 by Amd with its Athlon64 Cpus. Incapable Intel took a bit longer to bring out working 64-bit. So if you bought a PC within the last five years, it most probably will have 64-bit support.
Only exception there is netbooks with Intel Atom crap.

[Vistaus]

Re: CVE-2010-3081 kernel: 64-bit Compatibility Mode Stack Pointer Underflow

True, but most people will have Intel (which is crap, well except for the i-series). So most people will have a 32-bit CPU if their PC is >=4 years.