Slashdot Mirror

1) there is a huge, gaping bug in the OS

Its really a problem of API surface and complexity. Security is easy if you have 10 system calls to check for interactions. When you have 10k its an entirely different problem. Even so, it doesn't mean it can't happen, I'm reminded of the linux brk problem that existed for years (random google link http://www.isec.pl/papers/linux_kernel_do_brk.pdf). All it takes is one minor mistake, and group blindness and it can exist for years. There have been virtual machine exploits too. Of course the surface area for the critical parts of a VM are pretty small allowing it to be studied in detail.

Third question: Binary weighted tree in memory.

In the question was 9 digit number => you need 4 bytes to store it. You get one milion this numbers. => You need 4 MB of memory, but you have only 2MB RAM. Even if you choose to store it in just 30 bites, you still need 3.75 MB of RAM.

So you must somehow store data on network. Either by not sending ACK for some packets or juggling with packets.

See this security advisory: http://www.isec.pl/vulnerabilities/isec-0021-useli b.txt

You can use a local root exploit, such as the mremap(2) exploit. This exploit will allow any unprivileged account to gain root privileges and can be used to execute arbitrary code with kernel level access.

This is just an example. There are much better unpatched exploits if you look hard enough. A far simpler method is to just scan for improper file permissions.

Some applications or libraries (zlib) have overflow and stack exploits that can be triggered by improperly formatted user data. If you provide a user with a data file to exploit this (i.e. a zip archive), you can then have the application run code to take advantage of the local root exploit.

Then show me how that process would continue to other executables.

Once you gain root access, you can easily replace executables, shutdown services, install kernel modules, etc. The way many distros are set up, you don't even need root access to do some rather malicious things.

Then show me how that would spread from machine to machine, over the Internet.

There's a lot more remote exploits out there than you think. One of my favorites involves the Buffalo LinkStation. The Buffalo LinkStation is a network appliance that runs Linux and uses Samba to serve files. There's a really fun exploit on it that will allow you run any command as root simply by sending it a properly formatted UDP packet. At this point, you can drop an auto-run installer into the SMB shares and infect every Windows machine that connects to the LinkStation, but I digress...

Then please show me a case where that's actually happened.

Well, it basically all started with the Morris Worm.

Here are some Linux specific cases:

Viruses: Staog, Bliss, Osf, RST, Binom, Alfa, Lindose, Adrastea, Amalthea, Btrq, Brunfly, BTM, Califax, Cassini, Debilove, Etap.d, Gildo, Glaurung, Guile, Gzid, Mcmd, Metis, Millen, Nel, Neox, Ovets, Satyr, Sickabs, Snoopy, Thebe, Winter, Xone

Worms: Adm, Cheese, Mighty, Ramen, Slapper, Lion, Scalper, Adore, Kork, Mighty,

Juggling With Packets

(This was posted on slashdot previously: Slashdot 03/10/06/1049250 )

Perhaps gmail is a bit more reliable though

aloha,
dave

I suppose you mean this?
That's already fixed, thus proving GP's point.

Thank you for concentrating more on code to avoid things like http://isec.pl/vulnerabilities/isec-0021-uselib.tx t

It will be much more appreciated over here.

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

"Why is everyone saying these are fixed?" In the two links first, second is written, that they do not affect 1.7.5. Maybe because of that :-)

It's a real shame that such new was published the same day than
Isec's Two vulnerabilities that were published today.

It makes one think "It's not that good"

It's a real shame that such new was published the same day than
Isec's Two vulnerabilities that were published today.

It makes one think "It's not that good"

Here are some new vulnerabilities:

Linux kernel IGMP vulnerabilities von Paul Starzetz

Linux kernel scm_send local DoS von Paul Starzetz

Here are some new vulnerabilities:

Linux kernel IGMP vulnerabilities von Paul Starzetz

Linux kernel scm_send local DoS von Paul Starzetz

Sounds to me like you don't care for slashdot much. If that's the case, why are you here?

It's not that I don't like Slashdot in general, but I don't believe everything I read here.

Oh yes, let's just generalize for the purpose of making him sound like a moron. At least he's sticking to the topic, virus and how it exploits IE.

Everything he said applies to the Linux kernel too. He was trying to say that Windows is broken because it took so long for SP2 to be released. It took at least as long to get from the stable release 2.4 to 2.6 of the Linux kernel, so is that proof that 2.4 is broken? No.
Furthermore, he named no specific viruses, exploits in IE or anything else.

And you know this... How? Oh wait, let me guess, you read it on slashdot, so it must be true...

If it's so easy, then how come there aren't any provably safe/correct OSes in existance? The only provably correct software I am aware of run a few critical functions for orginizations that can afford the development: nuclear reactor computers, some of NASA's software. Nothing even approaching the complexity of Windows or Linux have even been attempted. Information is hard to link to because you have to pay for it. See http://archive.comlab.ox.ac.uk/procos/codesign.htm l, http://citeseer.ist.psu.edu/lin91provably.html, http://csd.informatik.uni-oldenburg.de/persons/ste phan.kleuker/s-kleuker.hti-abstracts.html.

No, he's not saying the Linux kernel is invulnerable. Far from it. He's saying Windows has far more vulnerabilities. No study necessary. Unless you're a total Microsoft Zealot, you should be able to see that as plain as day.

He specifically said the "heart" of Linux: I can only assume he is referring to the kernel. You've avoided that point entirely. The Windows kernel has equal or less vulnerabilities than the Linux kernel does. I dare you to name even one recent one that allows privlege escilation in SP2. Here is one in 2.6.0, and another in 2.6.6... Just ask Google

So you are saying that your position is so obvious and such common knowledge that you cannot find any support for it? That's called doublethink. If it was obvious, you should be able to provide copious, valid, fair and detailed sources to support your position. Stating that it's obvious without any support at all, as I posted earlier, destroys your credibility. No one is going to believe you just because you say it's true. That's the main problem I had with E-Rock-23, and now you.

Back off him, he does have a good point.

A point cannot be any good without support. He stated his case with zero references of any kind.

Besides, you're the one who posted anonymously

1. I don't see a name at the top of your post
2. What makes you think that's why I posted AC?
3. If your threshold is so high, how did you see the grandparent?

Internet Explorer runs entirely in user mode, in the security context of the current user. The only way to get more privledges from there is to exploit a local vulnerability in the kernel or some privledged service. Any user mode program can make use of a local vuln; IE and ActiveX are not special. Many operating systems have had local vulns; Linux patched one involving mremap() not too long ago. The local vuln in the article you linked to has been fixed since NT4sp4; it isn't going to work on 2k or XP. Besides, all the problems listed either exist on UNIXes too or have been fixed for 5+ years.

... with this, and Linux gets to join the "visit a malicious website and get rooted" crowd.

Myself and my partner have for the last 13 years been doing our best to raise our adopted son in the fine traditions of GNU/Linux and free software. Imagine my horror when, upon arriving home early from work yesterday, I caught my boy touching himself while looking at pictures like this!

Further examination of his hard drive (made easy by the numerous exploits possible with the Linux kernel) we discovered references to a despicable non-GNU OS and other subversive material.

What should we do? How can we guide our boy away from filth like this and back to the true GNU way?

-- Richard

The advisory was released Feb. 18, so this has all been public knowledge for over two weeks. This USENET post shows the vulnerability and upcoming exploit was known about, and slashdot is just plain late on this one.

You have had two weeks to patch your systems. I know slackware's advisory was sent right after the vulnerability became public knowledge.

Myself and my partner have for the last 13 years been doing our best to raise our adopted son in the fine traditions of GNU/Linux and free software. Imagine my horror when, upon arriving home early from work yesterday, I caught my boy touching himself while looking at pictures like this!

Further examination of his hard drive (made easy by the numerous exploits possible with the Linux kernel) we discovered references to a despicable non-GNU OS and other subversive material.

What should we do? How can we guide our boy away from filth like this and back to the true GNU way?

-- Richard

Myself and my partner have for the last 13 years been doing our best to raise our adopted son in the fine traditions of GNU/Linux and free software. Imagine my horror when, upon arriving home early from work yesterday, I caught my boy touching himself while looking at pictures like this!

Further examination of his hard drive (made easy by the numerous exploits possible with the Linux kernel) we discovered references to a despicable non-GNU OS and other subversive material.

What should we do? How can we guide our boy away from filth like this and back to the true GNU way?

-- Richard

Myself and my partner have for the last 13 years been doing our best to raise our adopted son in the fine traditions of GNU/Linux and free software. Imagine my horror when, upon arriving home early from work yesterday, I caught my boy touching himself while looking at pictures like this!

Further examination of his hard drive (made easy by the numerous exploits possible with the Linux kernel) we discovered references to a despicable non-GNU OS and other subversive material.

What should we do? How can we guide our boy away from filth like this and back to the true GNU way?

-- Richard

its been in the kernel since the 2.2 days .. the 2.2 series kernel's are also affected.

Is this true?

Surely the most relevant and comprehensive is the one at http://isec.pl ? it is mentioned in the FreeBSD advisory.

Oh really? But why NFS Bug was not been released to public on the same day, June 10, but rather a more than a month later when fixes were ready?

An anonymous writer at kerneltrap.org provided this link for a working exploit:
http://isec.pl/cliph/isec-ptrace-kmod-exploit.c

According to this report (repeated also on bugtraq), there is important security hole in Bitkeeper (found in November). Looking at the Bitkeeper pages I can't find any notification about the problem or the patch. In the Polish article the guy who found the vulnerability reports, that Larry McVoy just stopped replying to mails when they started discussing when the advisory should be published.

Leaving the but itself alone, the lack of information on their web pages and the lack of the patch after the advisory was published is - especially when talking about distributed internet application - very disguisting. The lack of information what has changed from version to version is disguisting too.

I backed bitkeeper in many discussions. No more.