Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

338 comments

Moo (0, Offtopic)

Chacham (981) | more than 7 years ago | (#18358445)

See! I told you ipv6 was evil!

An IP for everyone. Bah!

Amiga : ZERO exploits !! (2, Funny)

Anonymous Coward | more than 7 years ago | (#18358729)

Amiga : ZERO exploits !! About as many users !!

Re:Amiga : ZERO exploits !! (0)

Anonymous Coward | more than 7 years ago | (#18359367)

"Something wonderful has happened. Your Amiga is alive!"

Nope, the Amiga definitely had more than one exploit...

Re:Moo (4, Funny)

noz (253073) | more than 7 years ago | (#18358743)

See! I told you ipv6 was evil!
You mean ipv666 don't you?

Re:Moo (3, Funny)

BrainInAJar (584756) | more than 7 years ago | (#18358775)

An IP for everyone. Bah!

why, That's Communism!

Re:Moo (1)

HansF (700676) | more than 7 years ago | (#18359267)

Ipv4 was about 0.71 address per person, ipv6 is more like 47000 ip's per person.

WHOA WTF (2, Funny)

inode_buddha (576844) | more than 7 years ago | (#18358465)

freakin rare event, hell must have frozen over! /me takes a snapshot of the moment and feels badly for all the BSD-folk

Re:WHOA WTF (1, Funny)

Anonymous Coward | more than 7 years ago | (#18358491)

/me takes a snapshot of the moment and feels badly for all the BSD-folk

Yeah, us BSD folks are horrified when a bug is found. You Linux pups seem to think bugs are normal events.

(Yeah, I'm trolling, which is why this is anonymous.)

Re:WHOA WTF (0)

Anonymous Coward | more than 7 years ago | (#18358577)

I would've posted that with a username. Even being a "linux pup".

(I like BSD, too. (This is anon because it's pointless.))

Re:WHOA WTF (0)

Anonymous Coward | more than 7 years ago | (#18358709)

Naw. It, rightfully, got modded down. My karma remains in tact.

Re:WHOA WTF (0)

Anonymous Coward | more than 7 years ago | (#18358637)

freakin rare event, hell must have frozen over!
I'm surprised that it took this long. After all, the Red Sox won the world series almost two and a half years ago [boston.com] .

Re:WHOA WTF (1)

The Mad Debugger (952795) | more than 7 years ago | (#18358699)

Good thing we'll have Google Earth to show us the apocalpyse in progress [slashdot.org] .

Time to make a list... (5, Funny)

Anonymous Coward | more than 7 years ago | (#18359017)

-The Sox won the world series
-The Pope died
-Mac got Intel chips
-The Berlin Wall came down
-I out-lived 4 cats
-Man walked on the moon
-I got laid
and...
-BSD had a hole

Heh (5, Funny)

cyberbob2351 (1075435) | more than 7 years ago | (#18358467)

From TFA:

Remotely Exploitable: Yes
Locally Exploitable: No

That right there is the biggest slap in the face! Everyone should have the freedom to fux0r their own machine!

Opensource my ass...

Re:Heh (0)

Anonymous Coward | more than 7 years ago | (#18358739)

ohhh and yet another slap:
http://www.privasectech.com/?p=3 [privasectech.com]

Well, I guess that confirms it... (-1, Redundant)

bckrispi (725257) | more than 7 years ago | (#18358473)

BSD is dead.

Re:Well, I guess that confirms it... (1)

tfeserver (1065880) | more than 7 years ago | (#18358785)

Just OpenBSD. There are lot of other *bsd's.

Well done, the OpenBSD team. (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18358475)

Well done. It's not an easy feat to create an OS with so little exploits. The team and Microsoft should take a leaf out of your book.

Re:Well done, the OpenBSD team. (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18358571)

2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.

2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.

Could this be a sign of overconfidence in the Linux community?

Re:Well done, the OpenBSD team. (5, Funny)

Leto-II (1509) | more than 7 years ago | (#18358621)

Could this be a sign of overconfidence in the Linux community?


Not really, since this has nothing to do with Linux. It's OpenBSD, not Linux.

Re:Well done, the OpenBSD team. (1)

init100 (915886) | more than 7 years ago | (#18359125)

I've seen people more than once that believe that OpenBSD is a Linux distribution.

Re:Well done, the OpenBSD team. (0, Redundant)

EvanED (569694) | more than 7 years ago | (#18358625)

Could this be a sign of overconfidence in the Linux community?

Nope.

Now, it might be a sign of overconfidence in the BSD community...

(But in reality almost everyone has had moments like this.)

Re:Well done, the OpenBSD team. (0)

Anonymous Coward | more than 7 years ago | (#18358979)

Not surprising, just difficult, and platform specific I would imagine.

Re:Well done, the OpenBSD team. (4, Insightful)

Anonymous Coward | more than 7 years ago | (#18358575)

You think the problem is that Microsoft can't create a secure OS? You don't think the problem is all the legacy crap, and the everything under the sun and everything to everyone demands placed upon it? Not that what OpenBSD has achieved as a track record isn't impressive. But serving one master (of one's own choosing) well, it not the same thing as being the most favored servent to the most masters.

Re:Well done, the OpenBSD team. (5, Insightful)

Kandenshi (832555) | more than 7 years ago | (#18358579)

I heard a rumour that Microsoft did indeed look to the idea of emulating OpenBSD's security practices as a company.

Then someone pointed out the respective revenues of OpenBSD vs Microsoft, and the whole idea just seemed to evaporate.

Someone decided that people don't care enough about the number of remote exploits found in a given OS. They were probably right.

Re:Well done, the OpenBSD team. (3, Insightful)

drsmithy (35869) | more than 7 years ago | (#18358831)

Well done. It's not an easy feat to create an OS with so little exploits. The team and Microsoft should take a leaf out of your book.

It is when basically the only thing your OS does "in the default install" is allow SSH logins.

(Which is not to attack the excellent work of the OpenBSD team, but comparing it to Windows is in this fashion is just asinine.)

Re:Well done, the OpenBSD team. (5, Funny)

Tom (822) | more than 7 years ago | (#18359333)

It is when basically the only thing your OS does "in the default install" is allow SSH logins.
Which is more remote access than a default install of Windos contains. ;-)

Ok, make that "more intentional remote access"...

Sure it is (0, Flamebait)

Sycraft-fu (314770) | more than 7 years ago | (#18359203)

In fact Microsoft has an OS that has zero remote exploits in a default install: DOS. No remote access (net support wasn't a part of a default install), therefore no remote exploits. OpenBSD likes to wave their cocks around about it a whole lot but what it comes down to is the OS isn't really comparable to most default Linux or Windows installs. It does the "everything is off by default" tactic. Ok, fair enough, but that doesn't really mean anything. After all one could say virtually any OS that has a firewall that blocks all inbound traffic has no remote exploits by default since there is no remote access by default.

The real question isn't how many exploits there are in a default install, it is how many there are in a well maintained install in a particular environment. When you have a bunch of services opened up and running how well does something do?

I'm not knocking OpenBSD on the security front, I am just saying that their security claim isn't a real meaningful one in terms of overall secure design. It is just proof of the statement "If there is no service, there can be no denial."

Re:Well done, the OpenBSD team. (2, Funny)

VGPowerlord (621254) | more than 7 years ago | (#18359207)

The team and Microsoft should take a leaf out of your book.

What team, the A Team? Should take out Microsoft?

I love it when a plan comes together.

Re:Well done, the OpenBSD team. (2, Funny)

TheDarkener (198348) | more than 7 years ago | (#18359209)

...Microsoft should take a leaf out of your book.
 
Uhh, they did. TCP/IP stack.
 
Of course, you can't ever say a leaf made the tree...

It's a feature (4, Funny)

andy314159pi (787550) | more than 7 years ago | (#18358479)

Vulnerability Description
The OpenBSD kernel contains a memory corruption vulnerability in the code that handles IPv6 packets. Exploitation of this vulnerability can result in:
1) Remote execution of arbitrary code at the kernel level on the vulnerable systems (complete system compromise), or;
2) Remote denial of service attacks against vulnerable systems (system crash due to a kernel panic)

I think they just found the Windows2003 Server Emulator.

Re:It's a feature (4, Informative)

ArsenneLupin (766289) | more than 7 years ago | (#18358861)

I think they just found the Windows2003 Server Emulator.
Joking aside, finding a bug in BSD networking code could indeed mean that various Windows versions have that very same bug. Hats, to your keyboards!

Some amusing interchanges b/t OpenBSD and CoreLabs (2, Interesting)

Anonymous Coward | more than 7 years ago | (#18358483)

* 2007-02-20: First notification sent by Core.
* 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.
* 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
* 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
* 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.
* 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. Core requests details about the bug and if possible an analysis of why the OpenBSD team may or may not consider the bug exploitable for remote code execution.
* 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
* 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
* 2007-03-05: OpenBSD team notified of PoC availability.
* 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
* 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.
* * 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network.
* 2007-03-12: Advisory updates with fix and workaround information and with IPv6 connectivity comments from OpenBSD team. The "vendors contacted" section of the advisory is adjusted to reflect more accurately the nature of the communications with the OpenBSD team regarding this issue.
* 2007-03-12: Workaround recommendations revisited. It is not yet conclusive that the "scrub in inet6" directive will prevent exploitation. It effectively stops the bug from triggering according to Core's tests but OpenBSD's source code inspection does not provide a clear understanding of why that happens. It could just be that the attack traffic is malformed in some other way that is not meaningful for exploiting the vulnerability (an error in the exploit code rather than an effective workaround?). The "scrub" workaround recommendation is removed from the advisory as precaution.
* 2007-03-13: Core releases this advisory.



Got owned, OpenBSD? /I kid I kid

That's a relief (0, Funny)

Anonymous Coward | more than 7 years ago | (#18358485)


haha
luckily i'am running Windows so no remote exploits for me, take that OpenBSD !!!1@#x"3eleventy !

Advisory Timeline (4, Interesting)

fv (95460) | more than 7 years ago | (#18358499)

I'm a bit surprised that the summary didn't mention the rather interesting timeline in the Core advisory [seclists.org] , which implies an attempted cover up. I don't know all the facts, so I'll let the document speak for itself:

  • 2007-02-20: First notification sent by Core.
  • 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.
  • 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
  • 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
  • 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.
  • 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. Core requests details about the bug and if possible an analysis of why the OpenBSD team may or may not consider the bug exploitable for remote code execution.
  • 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
  • 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
  • 2007-03-05: OpenBSD team notified of PoC availability.
  • 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
  • 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.
  • 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network. 2007-03-12: Advisory updates with fix and workaround information and with IPv6 connectivity comments from OpenBSD team. The "vendors contacted" section of the advisory is adjusted to reflect more accurately the nature of the communications with the OpenBSD team regarding this issue.
  • 2007-03-12: Workaround recommendations revisited. It is not yet conclusive that the "scrub in inet6" directive will prevent exploitation. It effectively stops the bug from triggering according to Core's tests but OpenBSD's source code inspection does not provide a clear understanding of why that happens. It could just be that the attack traffic is malformed in some other way that is not meaningful for exploiting the vulnerability (an error in the exploit code rather than an effective workaround?). The "scrub" workaround recommendation is removed from the advisory as precaution.
  • 2007-03-13: Core releases this advisory.

-Fyodor
Insecure.Org [insecure.org]

Re:Advisory Timeline (5, Interesting)

evilviper (135110) | more than 7 years ago | (#18358585)

which implies an attempted cover up.

Cover up? The OpenBSD team believed it was only a remote DoS vulnerability until proof of concept code was provided, and re-labeled it as such immediately.

What part seems suspicious to you?

Re:Advisory Timeline (1)

jallen02 (124384) | more than 7 years ago | (#18358627)

The whole remote kernel panics aren't "vulnerabilities" thing goes counter to how the entire software industry classifies security bugs.

Re:Advisory Timeline (2, Informative)

Secret Rabbit (914973) | more than 7 years ago | (#18358707)

LOL. So, then the OpenBSD team isn't part of the software industry?

Because, they've never come up with anything security wise:

http://en.wikipedia.org/wiki/OpenBSD_security_feat ures [wikipedia.org]

Not at all.

Re:Advisory Timeline (0)

Anonymous Coward | more than 7 years ago | (#18359253)

OpenBSD didn't come up with any of those things. They aren't the first and definitely aren't the only
operating system to have them.

Re:Advisory Timeline (0)

Anonymous Coward | more than 7 years ago | (#18358749)

A denial of service is not a security concern dipshit, it's a reliability concern. Until it was proven to be anything other than a reliability issue it is muddying the the definition of what a vulnerability is to classify the issue as one. Fuck, you'd think this, "pablumfication," bit would sink in at some level.

Re:Advisory Timeline (1)

QuantumG (50515) | more than 7 years ago | (#18358951)

Go read a book, take a class or borrow a clue [yourwindow.to] about security.

Re:Advisory Timeline (1, Informative)

Anonymous Coward | more than 7 years ago | (#18359055)

Your link does not once say that a denial of service effects the security of a system, in fact, by definition a denial of service denies access to the service, it does not compramise it. If the shit ain't being broken into, it's not a security issue, get a clue, read abook, take a class, or maybe reason shit out your own damn self using simple logic.

Re:Advisory Timeline (1)

QuantumG (50515) | more than 7 years ago | (#18359135)

Availability is a key facet of security. There's no fuckin' point having a "secure" system which you can't even use.

You really look like an idiot debating this.

And I really look like an idiot trying to school an AC on Slashdot.

Re:Advisory Timeline (3, Insightful)

jrockway (229604) | more than 7 years ago | (#18359223)

> Availability is a key facet of security. There's no fuckin' point having a "secure" system which you can't even use.

Sure there is. Think, for example, of a data warehouse containing social security numbers. Would you prefer that that system go down entirely, or that the contents of the database is exposed. A system that detects trouble and shuts itself down until someone fixes it sounds good to me.

Also, by your standards, a power failure is a security hole. That's just not true.

Re:Advisory Timeline (0, Troll)

QuantumG (50515) | more than 7 years ago | (#18359261)

Ok. I'm done talking to you idiots now.

Re:Advisory Timeline (0)

Anonymous Coward | more than 7 years ago | (#18359291)

Oh oh. Seems you lost and can't admit it.

The "unlplug the computer to get a local security hole" is just too funnny.

Pwned. Get over it.

Re:Advisory Timeline (0, Troll)

toadlife (301863) | more than 7 years ago | (#18359319)

No. He won and you are the idiot.

Re:Advisory Timeline (1)

Anonymous Coward | more than 7 years ago | (#18358663)

I am not the GP, but ... remote DoS is not considered as a "vulnerability"!?

If this is not giving new meaning to old words, I do not know what is. The only reason for this I can think is cover up.

Re:Advisory Timeline (1)

LordEd (840443) | more than 7 years ago | (#18358589)

I wouldn't call it a cover up. I would say its a case of overconfidence. They didn't accept the fact that the buffer overflow was dangerous beyond a denial of service attack until it was proven to them. A denial of service attack in itself is more of a nuisance than a security risk.

They've earned a mulligan, I think (3, Insightful)

peacefinder (469349) | more than 7 years ago | (#18358763)

I'll spot them some skepticism or overconfidence. It's been proven again and again that they're right to think OpenBSD is a hard target, so it's understandable that they wanted to see proof before bumping their counter up.

As for a "cover up"... well, if such a thing happend I'd say they must really suck at coverups, since we all know about it. :-)

Re:Advisory Timeline (4, Informative)

fv (95460) | more than 7 years ago | (#18358873)

I wouldn't call it a cover up. I would say its a case of overconfidence.

That could be. And don't get me wrong -- I'm a big OpenBSD fan and even have one of their posters framed and hanging in my home. But I think they could have handled this better. Given that security is their main selling point, I'd like to see the OpenBSD guys treat all buffer overflows as potentially exploitable. In this case, it appears that the fix to 3.9 and 4.0 branches was delayed for an extra week until Core produced a working remote root exploit. The problem with requiring a working exploit from bug reporters is that most of them lack the ability or inclination (or both) to produce one. This bug just happened to be reported by some of the best exploit writers in the world.

Also, even if the bug did only allow anyone to cause remote kernel panic on your OpenBSD firewall or server with a single packet, that is still a security vulnerability. They can call it a DoS vulnerability if they are sure one cannot lead to code execution.

-Fyodor [insecure.org]

Not really a coverup... (1)

Grendel Drago (41496) | more than 7 years ago | (#18358593)

They just asked for proof of concept code before they'd declare a remote control vulnerability. That's not really much of a coverup. If you were OpenBSD, wouldn't you want to be really, really sure you'd found a remote root vulnerability?

Also, is IPv6 in the default install nowadays? If not, their slogan won't have to change.

Re:Not really a coverup... (0)

Anonymous Coward | more than 7 years ago | (#18358793)

I do not know what I would do if I were OpenBSD. Probably the wrong thing.

The responsible way to do is: if there is even a slightest chance of even DoS, it should be considered and announced as a potential vulnerability.

But, as painfully clearly pointed out, OpenBSD do not think DoS is a "vulnerability" - an insane redefinition of the word.

Anyway their slogan is so misleading (if not wrong).

Re:Advisory Timeline (0, Insightful)

Anonymous Coward | more than 7 years ago | (#18358643)

Hiya, Fyodor.

Why is your sig not a sig?

Re:Advisory Timeline (3, Insightful)

Secret Rabbit (914973) | more than 7 years ago | (#18358677)

I think you're reading too much into things. It's FAR more likely that the OBSD team has become somewhat overconfidenct in there code. As such, since remote exploit wasn't shown and was unlikely, they dismissed that.

But, cover up? Yah right. Please, note that the OBSD team NEVER denied that a problem existed. They fixed it. It was only the wording that was in contest until remote execution was shown and they verified it.

Obligatory (1, Funny)

Anonymous Coward | more than 7 years ago | (#18358507)

It was as if several dozen antiquated nameservers suddenly cried out in pain"

two (0, Troll)

mastershake_phd (1050150) | more than 7 years ago | (#18358509)

2 aint bad. Whats Microsoft at for the decade, 2000?

Re:two (0)

Anonymous Coward | more than 7 years ago | (#18358555)

Let me check...
What day of the week is it again...

Update the firewall? (1)

Psychotria (953670) | more than 7 years ago | (#18358511)

Perhaps it would be better to update the kernel

Re:Update the firewall? (0)

Anonymous Coward | more than 7 years ago | (#18358573)

Just don't install it. It's a rather unneeded package anyways...

Re:Update the firewall? (0)

Anonymous Coward | more than 7 years ago | (#18358845)

"Update the firewall" is in reference to OpenBSD being deployed heavily as a firewalling/packetshaping platform. It is my understanding that they weren't talking about updating PF, IPF or any other OpenBSD compatible firewall, but the OS itself (as the exploit is an ipv6 memory allocation problem in the kernel).

Doesn't matter how good a C programmer you are (2, Interesting)

Anonymous Coward | more than 7 years ago | (#18358529)

There will be buffer overflows. The solution is to not use C for handling data from over the network. Use a language that has memory safety. I think JNode [jnode.org] is on the right track. They have a small amount of code (assembly in this case) for running the virtual machine, and everything else is done in Java. Java has no memory access. Buffer overflows of a certain kind can exist but the standard buffer overflow exploit is nearly impossible.

I know, those who don't understand what I'm talking about will leap in and say, "Java has to run in a JVM and what language is the JVM written in? Ha! It's in C (or assembler) so it can still have buffer overflows!" This is so naive. First, the JVM runs Java code, which has no memory access. It does not run untrusted code handed to it over the net. Second, and most important, it is a very small piece of code with a rigorous definition of what it should do. It's possible to verify a small, rarely-changing bit of C code with a rigorous specification. It's not really possible to verify correctness of a huge constantly-changing C codebase, like the OpenBSD kernel and system utilities.

Anyway, trying to have a huge secure codebase in C is an exercise in futility, as OpenBSD has shown. Relative to other operating systems, OpenBSD is small and feature-poor. And their dev team must be among the best in the world for eliminating these types of bugs. And yet they still get bitten by them.

Re:Doesn't matter how good a C programmer you are (0)

Anonymous Coward | more than 7 years ago | (#18358611)

There's a reason operating system kernels aren't written in Java. Get a clue dude this isn't swing GUI userspace crap we're talking about here. Can you imagine virtual memory management? System.gc() // and cross your fingers.

Re:Doesn't matter how good a C programmer you are (3, Interesting)

Fnordulicious (85996) | more than 7 years ago | (#18358733)

Even the on the Lisp Machines the "kernel" code was implemented with manual memory management. There's a very simple reason for this. How do you implement the memory manager? It's a chicken and egg problem, so the lowest levels always have to do memory management by hand.

Also, it's less efficient to simply use one heap for everything. Instead, an OS kernel written in a language with automatic memory management usually maintains large blocks of memory for the various tasks to work in, like an area for packet construction, an area for I/O buffers, etc. The automatic allocator and GC are told which area to work in, and then create or delete stuff in that area as needed.

So no, it's not generally reasonable to implement the lower levels of any OS with automatic memory management. You're free to try, though.

Re:Doesn't matter how good a C programmer you are (1)

cryptoluddite (658517) | more than 7 years ago | (#18358995)

"alloc final class PacketBuffer ..."

Where that keyword tells the gc to use a separate allocation area for these objects. It's not hard to overcome the special challenges of kernel-level code in a safe language, it just takes a small amount of creativity. It's not like it hasn't been done before with Self, JavaOS, Singularity, etc.

The actual reasons why operating system are not written in safe languages today is a little bit of stupidity and a lot that user apps are written in unsafe languages. Making some random C program run fast inside a safe kernel is like making a safe language run well inside a C kernel; the right kinds of features you need just aren't there to make it fast. It's hard to realize the benefits of a safe kernel, like say being able to add fine-grained callbacks aka event listeners (this is essentially impossible with a C-based kernel due to separate memory spaces) when the vast majority of existing code could never use it. Just imagine how file change notification would be done with a safe kernel (ie addFileChangeListener -> done) vs the contortions and hideousness of inotify.

Re:Doesn't matter how good a C programmer you are (0)

Anonymous Coward | more than 7 years ago | (#18359163)

What's your implementation of alloc?

The actual reasons why operating system are not written in safe languages today is a little bit of stupidity and a lot that user apps are written in unsafe languages.

No, there are real reasons why operating systems are not written in "safe" languages. Despite over a decade of being told how great Java would be for writing a kernel, not a single Java developer has yet done it. So right now, we get to file the idea "Java would be great for writing a kernel and operating system developers are idiots" under the "Horseshit" category.

I have got to find the French version of /. (1)

Topherbyte (747078) | more than 7 years ago | (#18358537)

so I can purposely misspell their words and piss them off.

*BSD is dead (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18358543)

1990 called and wants its operating system back.

Barely "remote" (4, Informative)

_iris (92554) | more than 7 years ago | (#18358559)

"remote" in this case only means "not local." It does not, in any way, mean "far away," as the attacker has to be able to inject fragmented IPv6 packets, which is extremely hard to control (impossible?) from the other side of a layer 3 device.

Re:Barely "remote" (1)

LordEd (840443) | more than 7 years ago | (#18358615)

Most networks have multiple computers and devices. Odds are this system would hold more sensitive information and be used as a server. A successful attack vector would be to take over a less secure system to gain a foothold on the network, then use this attack to take over the main fortress.

Re:Barely "remote" (4, Informative)

pchan- (118053) | more than 7 years ago | (#18358617)

From the exploit text:

However, in order to exploit a vulnerable system an attacker needs to be able to inject fragmented IPv6 packets on the target system's local network. This requires direct physical/logical access to the target's local network


So nobody from the net can crack your machine, they must already me on your local net. This greatly reduces the scope of this attack.

Re:Barely "remote" (1)

perbu (624267) | more than 7 years ago | (#18358933)

Some people would even consider this a local exploit. An exploit which requires root access on a machine on the local network is hardly, uhm, remote.

Re:Barely "remote" (1)

Kuciwalker (891651) | more than 7 years ago | (#18358945)

It means that anyone on the wireless at Starbucks, or who plugs a laptop into the network at work, can own your box. That's a security issue.

Re:Barely "remote" (1)

dougmc (70836) | more than 7 years ago | (#18358971)

Some people would even consider this a local exploit.
Then those people would be fools. Local means local -- you have to have access to the box in question already.


Granted, as far as remote exploits go, this one is pretty hard to exploit (since it needs IPv6 and access to another box on the same subnet), but it's still a remote exploit. It just means somebody has to exploit that Windows box on the same subnet (which may be a simple matter) and use THAT to attack the OpenBSD box.

If the OpenBSD box is at a colo, the odds of having other boxes on the same subnet that could be easily hacked and used to inject this attack are pretty high.

Re:Barely "remote" (1)

Kjella (173770) | more than 7 years ago | (#18359137)

Some people would even consider this a local exploit. An exploit which requires root access on a machine on the local network is hardly, uhm, remote.

Take over one box at a colo (e.g. fully remote exploit, local account and a really local exploit, pay for it with fake credit card, whatever) then take over any other server on the "LAN"? Or like the University I went to, they had network plugs outside the computer labs in public areas so you could sit there with your own machine. I don't know the physical layout, but if that put you on the same LAN as a computer lab you've certainly come far. Ok so it's maybe not long distance but it's certainly far more dangerous than a purely local attack.

Re:Barely "remote" (1)

kestasjk (933987) | more than 7 years ago | (#18359255)

It is more dangerous than a purely local attack, but you shouldn't be able to inject fragmented IPv6 packets from a shared account anyway. You would need to be able to write data directly to the wire, which users in any modern OS can't do.

If security was a concern in a shared hosting environment you could make it so that even root can't inject fragmented packets.

I'd say the scope of this vulnerability is very limited, the most disturbing thing is the way the OpenBSD team tried to hush it up.

OpenBSD - now TWICE as insecure (3, Funny)

Anonymous Coward | more than 7 years ago | (#18358567)

Wow, OpenBSD's security rating just went from "999,999" on a scale of 1 to a million to "999,998" on a scale of 1 to a million.

Re:OpenBSD - now TWICE as insecure (0)

Anonymous Coward | more than 7 years ago | (#18358761)

Wow, OpenBSD's security rating just went from "999,999" on a scale of 1 to a million to "999,998" on a scale of 1 to a million.

As opposed to Microsoft, which is still trying to break out of the negative numbers.

I kid! I kid! Actually, they did that some time ago. They're now up to around "2" on a scale of 1 to a million and rising.

Re:OpenBSD - now TWICE as insecure (1)

Shadyman (939863) | more than 7 years ago | (#18359039)

Or it's gone from 1 in 1 million to 1 in 500,000

Holy Cow, an OpenBSD Vuln? (5, Funny)

Anonymous Coward | more than 7 years ago | (#18358651)

Thank GOD I run the company webserver on NT!

Not in the default install (0)

Anonymous Coward | more than 7 years ago | (#18358697)

For this to manifest itself, you will have to manually enable IPv6, which is NOT on in the default install. Thus OpenBSD can keep its "x years without a remote hole in the default install" claim.

Re:Not in the default install (4, Informative)

dmiller (581) | more than 7 years ago | (#18358769)

No, IPv6 is enabled in the default install, though it does use only link-local addresses by default. This means that the attacker has to be on the same layer-2 network as the victim, but this is still classified as a remote exploit. Theo agreed, and the homepage [openbsd.org] has already been updated.

Remote exploit? (0)

Anonymous Coward | more than 7 years ago | (#18358859)

I dunno - seems if you need a local connection to the computer, even if through a few ethernet cables and a hub, it's not a remote exploit. I mean, if there was an exploit that could only be taken advantage of by a USB packet after passing through several hubs, it would still be considered a local exploit.

Re:Remote exploit? (0)

Anonymous Coward | more than 7 years ago | (#18358885)

No, remote is anything not on the local machine, rather than anything not on the local network - trust this guy, he's DJ Miller, one of the OpenBSD MCs.

who the hell.. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18358829)

..uses IPv6? That's the first thing I turn off on every OS I've ever set up for a client (at least, ones where I can recompile the kernel).

This is about as interesting as finding a hole in Gopher. (Except, well, Gopher is something from the past, and IPv6 is perpetually in the future [any day now, we'll all switch!]).

Hats off (1)

NonViviDaSola (1010423) | more than 7 years ago | (#18358855)

My hat is off to Core Systems. This takes a lot of dedication as needles in the BSD haystack are very small indeed. I'm curious as to whether this was found by protocol fuzzing.

I loved how core was... (1)

rivaldufus (634820) | more than 7 years ago | (#18358899)

gloating. Perhaps they know of an OS with a better record?

Re:I loved how core was... (1)

Aim Here (765712) | more than 7 years ago | (#18359301)

Maybe they're gloating because it's not easy to get an OpenBSD vulnerability, unlike certain other OSes we can mention. Moreso, even, because their work will hit the front page of an Operating System's website. That doesn't happen every day if you're a security professional. Well, not unless you're Bruce Schneier [geekz.co.uk] of course...

Maybe we should see the same thing on the Microsoft website: "Welcome, users. It has been 43 hours since our last remotely exploitable vulnerability in the default installation

pablumfication (2, Interesting)

vocaro (569257) | more than 7 years ago | (#18358915)

Can anyone explain what pablumfication means? The only hit [google.com] is the very same report. I thought maybe it was pablumification [google.com] , but that only gets two more hits.

Re:pablumfication (3, Interesting)

chenjeru (916013) | more than 7 years ago | (#18359035)

While 'pablumification' does seem to be a newly made word, the root 'pablum' is a bland children's porridge. The ever-handy Wikipedia has this to say:

_In lower case, the word pablum is often used to describe anything bland, oversimplified and generally unsatisfying, especially a work of literature or speech. This usage is thought to derive from the cereal. Today, the word pablum and the original Latin word pabulum are often used interchangeably. In Canada, pablum remains as a generic reference to any instant baby cereal.

_The phrase 'pablum puking', when used in political speech, is used to describe one who seems to lack the ability to digest simple logic or common sense. For example, someone who holds forth the argument that children should be afforded the freedom to play in traffic could rightly be refered to as a 'pablum puking idiot'. ..thus, the poster's creation of the word in reference to oversimplification.

Re:pablumfication (2, Informative)

Cheapy (809643) | more than 7 years ago | (#18359075)

Sure. Look at the given text for the first google hit. It says "disneyification." This lead me to believe this term was referring to "pablum". So I looked that up, and found out that "pablum" is used to describe oversimplification of something.

Wikipedia has a good entry on Pablum.

The juicy bits (-1, Redundant)

sanermind (512885) | more than 7 years ago | (#18359107)

# 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.

# 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. Core requests details about the bug and if possible an analysis of why the OpenBSD team may or may not consider the bug exploitable for remote code execution.

# 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.

# 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.

Pwned!!!! ...ahem

OpenBSD Website (5, Informative)

Anonymous Coward | more than 7 years ago | (#18359123)

From the OPENBSD Website:
Only two remote holes in the default install, in more than 10 years!

At least they don't hide it.

Needless sensationalism (0)

iamacat (583406) | more than 7 years ago | (#18359227)

This bug just crashes the machine. Anyone who uses a desktop or notebook knows that crashes happen from time to time, regardless of the OS. There is no known way to run attacker's code, and TFA suggests that there is unlikely to be one.

Re:Needless sensationalism (1)

pinky99 (741036) | more than 7 years ago | (#18359263)

Did you ever heard something about Denial-of-Service - attacks? Especially when OpenBSD is preferrably used on routers, firewalls and gateways, with a high number of connected clients, a lot of other machines are dependant on this service...

Re:Needless sensationalism (1)

pinky99 (741036) | more than 7 years ago | (#18359281)

Did you ever come to hear something about denial-of-service attack? Especially in the case of OpenBSD machines, running often on firewalls, routers and gateways, a lot of other machines are dependant on this service...

More popular than you thought (1)

minus9 (106327) | more than 7 years ago | (#18359235)

OpenBSD is only a target because it is so ubiquitous. If Microsoft windows ever becomes as popular, it too will become the target of such attacks. ;)

If only.... (0, Troll)

leereyno (32197) | more than 7 years ago | (#18359317)

If only OpenBSD were suitable for anything beyond a firewall.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...