OpenBSD Will Not Fix PRNG Weakness

snake-oil-security writes "Last fall Amit Klein found a serious weakness in the OpenBSD PRNG (pseudo-random number generator), which allows an attacker to predict the next DNS transaction ID. The same flavor of this PRNG is used in other places like the OpenBSD kernel network stack. Several other BSD operating systems copied the OpenBSD code for their own PRNG, so they're vulnerable too; Apple's Darwin-based Mac OS X and Mac OS X Server, and also NetBSD, FreeBSD, and DragonFlyBSD. All the above-mentioned vendors were contacted in November 2007. FreeBSD, NetBSD, and DragonFlyBSD committed a fix to their respective source code trees, Apple refused to provide any schedule for a fix, but OpenBSD decided not to fix it. OpenBSD's coordinator stated, in an email, that OpenBSD is completely uninterested in the problem and that the problem is completely irrelevant in the real world. This was highlighted recently when Amit Klein posted to the BugTraq list."

Comments

then exploit it (if you can)

[Anonymous Coward]

if you think its a problem, exploit it
nothing says "fix it" faster than a few thousand compromised hosts
release a PoC that gets r00t, inform the security lists and stand back
thats what full disclosure is for.

if it isnt exploitable then BSD can fix it at leisure
or if thats not quick enough and as its Open Source, YOU fix it if you are that concerned

now somebody call the whhaaambulance

Re:then exploit it (if you can)

[Anonymous Coward]

Maybe you're right but I was always very concerned about randomness of my random numbers, to the extent that when my friend explained some of the flaws of .NET's Random class' implementation, I rolled my own for the project we've been working on.

After all random numbers are supposed to be *random*.

Re:then exploit it (if you can)

[aliquis]

Kinda hard to make some if nothing in our world are truly random. Or is anything? Would be cool if there was an algoritm for the past, present and future of the whole universe and everything within ;D

Re:then exploit it (if you can)

[digitig]

If you're working at the level where a friend has to explain the weaknesses in a PRNG class, one you roll yourself is highly unlikely to be better. There are many algorithms out there that have been very thoroughly analysed and explored by experts, and there's going to be one out there that's easy to find and better than your hand-rolled one. And, of course, what count as "weaknesses" depends on the application. A PRNG that's great for Monte-Carlo simulation may be too predictable for cryptography. A PRNG that's sufficiently hard to predict for cryptography may be too slow for Monte-Carlo simulation.

Re:then exploit it (if you can)

[maxwell demon]

Kinda hard to make some if nothing in our world are truly random. Or is anything?

Quantum mechanics delivers true randomness, at least according to the standard interpretation.

Re:then exploit it (if you can)

[argiedot]

Or by using radiation (If I remember high school science): http://www.blackcatsystems.com/GM/random.html

Re:then exploit it (if you can)

[Jugalator]

if you think its a problem, exploit it http://www.securityfocus.com/bid/27647

Re:then exploit it (if you can)

[Jugalator]

Wow, Slashdot ate my whole comment besides that link... A bug?

Anyway, besides rudely just posting a link like that in response, I was going to say that proof-of-concept code has at least already been published, and his point is that FreeBSD, NetBSD, DragonFlyBSD has fixes available. Apple is currently working on a fix for OS X. OpenBSD is not planning to fix this. More info can be found in my parent link.

Re:then exploit it (if you can)

[orgelspieler]

I wrote a program like that once. It kept on outputting 42.

Re:then exploit it (if you can)

[that this is not und]

True, but if you roll one yourself, the P in PRNG no longer has a second meaning of 'predictable.'

Re:then exploit it (if you can)

[alexhs]

Wow, Slashdot ate my whole comment besides that link... A bug? A bug indeed, and it is yours, apparently you can't code in HTML :P
You probably did a typo in a closing tag. Anyway, There's a reason why we have a "preview" button ;)

Re:then exploit it (if you can)

[evanbd]

Resistor thermal noise is also inherently quantum in origin, and much easier to measure. All it takes is a resistor, a good analog amplifier, and an A/D converter -- which could all fit on a single piece of silicon if you wanted.

Re:then exploit it (if you can)

[Anonymous Coward]

haha

"r00t"

Re:then exploit it (if you can)

[digitig]

True, but if you roll one yourself, the P in PRNG no longer has a second meaning of 'predictable.'
It does if you don't do it right, and you're unlikely to do it right unless you're a cryptographic expert. Just because your algorithm isn't published doesn't mean a competent codebreaker won't be able to crack it: ahref=http://en.wikipedia.org/wiki/Security_through_obscurityrel=url2html-8229http://en.wikipedia.org/wiki/Security_through_obscurity>.

Re:then exploit it (if you can)

[Anonymous Coward]

This is a pseudo-RNG, not a RNG.

It is not random. Just nearly.

Re:then exploit it (if you can)

[Anonymous Coward]

So did I:

10 PRINT "42"
20 GOTO 10

Re:then exploit it (if you can)

[Anonymous Coward]

Whaaaaaaaaaaaambulance!

This is all a bunch of nonsense. You can't poison DNS caches without either a) compromising an upstream DNS server or b) compromising an upstream router. *Perhaps* you could DoS the upstream router, take over its IP, become the router yourself (assuming you have some other route to the outside), hope nobody served by that router notices that half the internet is dead, and then masquerade as the upstream DNS server. Then of course if you want to really do damage you'll need to forge SSL keys. But none of this requires cracking the PRNG.

Name servers are not a system for trust. Cryptography is.

Re:then exploit it (if you can)

[SlashWombat]

Actually, It is normally a transistor set up to be noisy, and used to drive a digital bit into a shift register. (I have seen that trick used in several different encryptors, and it works very well!)

I would have thought all algorithmic solutions to random number generation would suffer the same flaw as described in the text. Be in deep shit if it worked any other way.

Re:then exploit it (if you can)

[Anonymous Coward]

Anyway, besides rudely just posting a link like that in response, I was going to say that proof-of-concept code has at least already been published

Proof-of-concept code that shows that it's possible to predict the next number, yes. But merely predicting the next number isn't an exploit unless you can then use that prediction to do something malicious, right?

I looked around the page you linked to looking to see what malicious things this bug allows, and all I saw was a whole lot of "potentially this, possibly that" scenarios. Well, yeah, and it says on my medicine here that taking one pill might possibly cause side effects like sudden death. The point is that unless there's actual evidence that this bug can be used maliciously, why get so worried about "potential" exploits?

Re:then exploit it (if you can)

[blincoln]

In the analogue synthesizer era, it was common to use a Zener diode as a noise source. Here's an older writeup about a simple circuit with cryptography in mind. The A/D converter in this case is the one on the author's sound card.

Re:then exploit it (if you can)

[aliquis]

I know waaay to little about quantum physics, I've never understood this can't measure it without changing it stuff or whatever =p, so I have a hard time arguing in either way regarding it. But I do guess there must be a spin and that you should be able to find out what it is just that our methods of reading it interferce with it or something? Kindoff useless to try to discuss it when I know so little about the subject thought. Would be intresting to know more.

Re:then exploit it (if you can)

[billcopc]

I second that statement. If OpenBSD refuses to fix it, and you think that's wrong, then prove them wrong.

Personally, I think OpenBSD should simply be left alone to die peacefully. I simply cannot stand that squirrelly OS.

Re:then exploit it (if you can)

[mysidia]

False. The attack method is you give the DNS cache a query and you flood a spoofed response from the upstream DNS server. I.E. You forge a response of your own and deliver it to the cache before the upstream response comes in. In this manner, the DNS cache will believe _you_ are the upstream DNS server. Once it accepts your response, the query is over, and the real upstream's response will be discarded.

Since DNS utilizes UDP, there is no TCP stream you need to inject to or hijack (no 32-bit sequence numbers you need to figure out).

The only difficulty to poisoning in most cases should be you need to guess the right 16-bit ID. Some DNS cache software (notably... djbdns dnscache) randomizes the source port, in that case you need to guess the source port too, making the probability of successful poision very SMALL (but still possible): however, BIND uses a fixed source port of 53, so you only need to guess that 16-bit ID to spoof the DNS response.

Of course, for popular domains, on a high-traffic DNS server, the _right_ NS data is probably already cached, and it would be difficult to poison. The correct data would have to expire, and your poison would have to arrive at the right moment by chance, but an attacker could pick popular domains at random until they discover one that's not cached, or wait it out, and repeat the attack attempt at every TTL expiration...

Re:then exploit it (if you can)

[jadavis]

Would be cool if there was an algoritm for the past, present and future of the whole universe and everything within ;D

Sure, it's called "The Laws of Physics".

The only problem is, nothing can calculate the result faster than our universe is already doing. It's hard to make something that can calculate the behavior of a quark that is smaller than a quark.

Re:then exploit it (if you can)

[maxwell demon]

Well, let me try to explain.

Imagine a spin-1/2-particle (e.g. an electron). Such a particle has the peculiar property that if you measure its spin along any chosen axis, you'll always get either 1/2 ("spin up") or -1/2 ("spin down").

OK, let's assume we have just measures the spin in z direction and got +1/2. Let me first note that this is stable: If we measure the z-spin of the same particle again (assuming it didn't interact in between), we will again get +1/2 each time. That is, once we measures +1/2 in z direction, every subsequent measurement will confirm that result (this may seem trivial, but it will be important further down).

Now we want to know: What is the spin in x direction? Well, it can neither be 1/2 nor -1/2, because we've "used up" all of the spin for the z direction. OTOH +1/2 and -1/2 are the only allowed values; 0 is not a possible value.

But then, if we want to know the spin in x direction, after all we can just measure it. If we do so, we indeed find either +1/2 or -1/2, and never anything else. Moreover, we find that in half of the cases we get +1/2, and in the other half we get 1/2, so on average the x spin indeed is zero, but for each single measurement we get either +1/2 or -1/2. And that value also turns out to be stable: If we repeat the x-spin measurement, we get the same value again.

Well, now we could say, maybe we just got all wrong about spin, and in truth electrons have separately an x spin of +1/2 and -1/2 and a z spin of +1/2 or -1/2 (and the same for any other direction), and what we've found is just that half of our electrons are electrons with "+" spin in one direction, and "-" spin in the other. Now, let us test that hypothesis.

We now only look at electrons which were found to have spin +1/2 in z-direction, and subsequently found spin +1/2 in x direction. OK, if the above hypothesis holds, if we now again measure in z-direction, we should again confirm the value +1/2, because after all, that value is stable, right? Well, what we find is that only in half of the cases we find z-spin +1/2, but in the other half we find z-spin -1/2! So somehow by measuring the x-spin, we destroyed the value for the z-spin.

Indeed, by measuring the spin value in one direction, we destroy the spin value for any other direction. The latest measurement destroys all information gained through previous measurements, so that if we know what we measured last (i.e. both the direction we measured in, and the measurement result), we know everything we can know about the spin. The results of previous measurements don't add any knowledge about future measurements. If we measured +1/2 on one measurement, the probability to get +1/2 on another measurement depends only on the angle of our new measurement direction to the previous measurement (and the same of course for -1/2). The smaller the angle, the more probable is it top get the same result for the new direction (measuring again in exactly the same direction reliably gives the same result again, as noted above). If we measure in a direction perpendicular, the results are completely uncorrelated to the previous measurement result; we get just +1/2 or -1/2 with 50% probability each.

So measurement obviously destroys whatever state the electron spin had before, and establishes a new state according to the result we got.

Re:then exploit it (if you can)

[sempernoctis]

There is a difference between normal pseudo-random numbers and secure pseudo-random numbers. Generating data that is sufficiently random for security purposes takes a lot of work. In Java, the Random class generates non-secure pseudo-random numbers, and the SecureRandom class generates numbers suitable for security applications (at increased computational cost). I would expect .NET does something similar.

Re:then exploit it (if you can)

[Sam Ritchie]

There is - see System.Security.Cryptography.RNGCryptoServiceProvider. People like GP really give .NET devs a bad name.

Re:then exploit it (if you can)

[Iron Condor]

Kinda hard to make some if nothing in our world are truly random.

Almost all processes in a computer are truly random. The number of electron crossing this particular trace per second? It's certainly not constant.

The trick in computers is keeping the RAM and the harddisk from going random too fast, such that a temporary illusion of determinism can be achieved. A crossing cosmic-ray particle will flip every last bit at random -- it'll just take sufficiently many centuries that you can imagine your bits to be stable zeros and ones.

Back in the eighties I generated truly random numbers on my old Atari by looking into the sound-chip with a port and cranking up the noise-generator on that chip. The noise-generator was just a fat resistor with a big amplifier attached to it. Quantum-randomness through thermodynamical means -- right there. Why do programmers today have trouble doing similar tings?

Re:then exploit it (if you can)

[evanbd]

Yeah, other sources are similar, and Zener diodes are probably the easiest devices to produce noisier versions of (and still maintain high noie quality). I mention resistors mainly because the physics behind them is the easiest to understand.

Re:then exploit it (if you can)

[chthon]

Because it is not part of the standard PC architecture ?

Re:then exploit it (if you can)

[Anonymous Coward]

If you're working at the level where a friend has to explain the weaknesses in a PRNG class, one you roll yourself is highly unlikely to be better.

Or as Knuth more concisely puts it:

Random numbers should not be generated with a method chosen at random.

Re:then exploit it (if you can)

[Lisandro]

Creating a fairly strong PRNG is easy - get a seed, and hash it with a few different algorithms (MD5, SHA-512, Whirlpool, etc). Extract a number of bits as your pseudorandom output and then use the whole output as a new seed for the process. You can get fancy with the seed and keeping internal states to change the hashing ordering.

Re:then exploit it (if you can)

[digitig]

Read Knuth on that one -- he points out cases where people have done similar things and ended up with particularly /poor/ generators. Even if you did end up with a good generator, how would you know you had?

Re:then exploit it (if you can)

[Anonymous Coward]

And if you the zone is signed you can cryptographically verify the response
and not need to worry about whether the id is guessable or or that the
attacker is sending a flood of responses.

There is a solution in the DNS space. There are free implementations that
run on just about every platform.

Uh what

[Brian Gordon]

Is the summary just supposed to be as shocking as possible? How about some details on why specifically they decided not to patch it?

Re: Uh what

[Dolda2000]

I'm no security expert and I don't know anything about the attack vectors that he claims, so maybe I shouldn't say too much, but I do know this: TFA mentions that the PRNG is used for such fields as DNS transaction IDs and IP header fragment IDs, and these fields were never even meant to be random from the beginning. Verily so, TFA even says that {Free,Net}BSD don't even use the PRNG by default, but uses sequential numbers unless a certain sysctl is tweaked.

Thus, it is my guess that even if the attack vectors are deemed serious enough, the OpenBSD team has decided that it doesn't matter, since these protocols were never designed for security anyway, and that one should use DNSSEC and/or IPSEC (or TLS) if one actually wants to be secure (it does raise the question as to why they decided to use a PRNG for those fields from the beginning, though). My second guess is that they don't even consider the attack vectors serious, though, since they probably require a cracked router to be effective anyway.

Indeed, if they do require a cracked router, then I don't see the issue to begin with. One of the attacks was that the attacker could inject data into a TCP stream and such things, and if he has a router cracked, then I'm pretty sure he could forge all the data he wants anyway, without using any particular software attack at all, and likewise with DNS data.

Re:Uh what

[Zeinfeld]

Is the summary just supposed to be as shocking as possible? How about some details on why specifically they decided not to patch it?

It is entirely believable to me. Back in 1995 I told Marc Andressen at Netscape that he had a serious problem with the random number generator used to choose session keys for SSL. There was simply not enough randomness going in for there to be 128 bits going out.

Marc had every reason to listen to me, I had broken SSL 1.0 in ten minutes when he tried to demonstrate it at MIT. But it took several weeks to drill the problem into his thick skull.

So they eventually asked me for a description of how to do the thing right.

A year later the exact same bug was discovered independently. By this time they had hired some competent crypto people. I spoke to Taher about the problem later and his explanation was that they found the design note on the PRNG which was so comprehensive that they didn't think it necessary to check the actual code.

Re: Uh what

[Anonymous Coward]

What if the router is OpenBSD?

Re:Uh what

[Anonymous Coward]

Is the summary just supposed to be as shocking as possible? How about some details on why specifically they decided not to patch it? It is entirely believable to me. So they both use pseudo-random numbers! Got it. Since this was fixed 10 years ago at Netscape, everything is OK.

Phew! I was concerned about surfing over to a BSD-based website, but now I know everything is OK. Time to move on.

Re: Uh what

[Dolda2000]

Yeah, what if? It's not as if any of these attack vectors would let you compromise a system, at least not by themselves.

Re: Uh what

[Anonymous Coward]

The idea behind the suggested attack vector is to find a way of sending matching packets *without* sitting in the path of the data. If you can guess certain values which the server will send to other hosts with a high probability and do so just by looking at packets which the server sends as answers to your requests, then you can spoof packets and other hosts will accept your misleading payloads as though they were coming from the server.

Re: Uh what

[Dolda2000]

Really? If that is truly so, then I'd argue that that is what is the actual security flaw, and not the non-randomness of the IDs. For sure, you won't be able to carry out any of the IP attacks that way, since fragment IDs are local to the sending host. To be honest, I didn't understand how the DNS vulnerability worked to begin with (I didn't see it being explained anywhere), so I can't make any statements about it, though.

Re: Uh what

[Anonymous Coward]

Actually, forget that. You want to send a reply to a request packet that someone else got from the server. It doesn't make sense the other way around. You need to guess what the server sent to the other host so that you can reply accordingly. If you can guess the value that the server sends and expects back in the valid response, and send an answer before the true answer arrives, you can poison DNS.

Re: Uh what

[Smallpond]

The reason that they weren't designed to be secure is that noone had thought of the "DNS poisoning" attack when the protocols were designed. If they had, they would have made the ID field longer. Since it is only 16 bits, I doubt that there is any very secure way of protecting someone from guessing the next value. The paper describes a method of narrowing it down to 8 possibilities by doing ~10^9 calculations.

The exploit described in the paper doesn't require a cracked router, just a malicious website. Once you can inject fake DNS entries for bankofamerica.com or ebay.com on some ISP's DNS server, the exploit has paid for itself.

Re:Uh what

[fulldecent]

You cracked Marc's 128-bit encryption, but your Slashdot id is 263942. Doesn't add up.

Re:Uh what

[Anonymous Coward]

Is the summary just supposed to be as shocking as possible?

Well, this is SheepDot we're talking about, so... yes?

Re:Uh what

[LizardKing]

That's because he's so l33t he can pick a Slashdot id at random every time he posts.

Re:Uh what

[that this is not und]

What does the size of a slashdot UID have to do with anything?

I work at a company where there seem to be continual '30 year awards' at employee meetings. Some of the worst dead-wood dullards stand up and go to the front to receive those awards.

People come and go around here.

Re:Uh what

[Alcoholic Synonymous]

For the same reason they claim that "stealth" firewalling is only "security through obscurity" and never acknowledge the sheer sense of not revealing jack shit a would be attacker. It goes against the group think, Theo de Raadt said it somewhere, so it's unquestionable.

It's by far easier to yell, scream, point fingers, and name call than it is to write a truly secure OS. They built a pretty impressive house of cards around being proactively secure, but over the past year or so the hype has fallen short. Mostly, this is due to not acknowledging problems that they have, from the IPv6 bug that turned out to be a remote hole, to the simple FTP client that wasn't keeping connections open (they actually blamed firewalls for this one), to this PRNG bug which everyone has patched except them (and CRApple). There are more examples, basically just look for really long threads of name calling on MARC, this is how the real problems end up. They are a vitriolic (or is that viTROLLic?) community who insults anyone who questions their kooky decisions (Apache in base, Perl in base, Xorg in base, branch tagging ports in CVS, the 8GB boot loader limit, the lack of hardware acceleration support).

I have used OpenBSD for 5 years now, but will be migrating to FreeBSD in the near future. They can have their hype, I would rather have functionality, performance, frequent updates, a helpful user community, and PROACTIVE SECURITY. That's right, OpenBSD isn't the only OS to think about how to keep people out, but they are the only ones who claim their poor performance is caused by the measures, at least until they get around to patching the real cause.

Reading stuff where they refuse to patch known problems, and this is actually far from the first, is icing on the cake to my decision.

Re:Uh what

[Omnifarious]

I have noticed that people are complete and utter idiots about two very important cryptographic algorithms. PRNGs and hash functions. I can't believe the number of people who still use a simple MD5 hash for software download verification. First, it isn't signed, so all someone has to do is alter both the hash and the code. Secondly, even if it were it's not very hard to make two pieces of code, one innocuous and one malicious that both have the same MD5 hash, and it's been true for years.

DNS cache poisoning is a real danger. I bet someone dedicated could set up a website and evil exploiting DNS server pretty easily. You sprinkle some things in the website that will make a predictable series of requests for names in the domain of the evil DNS server, then a request for the name of bankofamerica say. Then the evil DNS server spits out the IP spoofed evil answer with the predicted sequence number for bankofamerica so the target computer gets it instead of the legitimate answer from their own DNS server. Bonus points if you can poison an ISPs recursive DNS server, then all their customers will go to the evil bankofamerica instead of the real one.

IP sequence number prediction is likely a much lesser danger because if you're in a situation where it can be exploited the router is likely compromised anyway. At least, I can't think of a way to exploit it without compromising a router.

But, regardless, if you have a PRNG in place to make a certain number unpredictable, you ought to actually care enough for the fix to actually make it that way. Either have code that works, or no code at all, not some half-assed piece of garbage that someone might mistakenly trust. Just because it runs doesn't mean it works. Anybody with that mindset should never be placed in charge of something security sensitive.

Re:Uh what

[Anonymous Coward]

The real old-timers don't register for websites.

Re: Uh what

[Anonymous Coward]

>Yeah, what if? It's not as if any of these attack vectors would let you compromise a system, at least not by themselves.

And if you're that worried about it, don't run DNS on your OpenBSD router.

Re:Uh what

[Anonymous Coward]

Zeinfeld, aka Phillip Hallam-Baker is the CTO of Verisign, and while he occasionally makes outlandish claims about himself and his past on Slashdot, most of those claims are well-grounded in reality.

On SSL/TLS and similar security/crypto issues, he is always interesting and more likely to be right than not.

On supporting large scientific computing platforms, he is always interesting and more likely to be right than not. His system administration c.v. is impressive.

On interpreting the experiments performed on those platforms and the results achieved, he is occasionally interesting but is much less often right than in those other areas. Unfortunately, he tends to exaggerate his area of expertise and the basis on which he was awarded his doctorate in arguments from authority.

Doesn't add up

Since most of this is readily found via your favourite Internet search engine, including the search box at the top of every slashdot page, you can easily check your own initial addition.

Re:Uh what

[gatzke]

Low slashdot id doesn't mean much. They used to give accounts to anyone...

Re:Uh what

[Anonymous Coward]

They used to give accounts to anyone...

...and their standards have declined over time :)

Re:Uh what

[homesteader]

You must be new here

Re:Uh what

[jonadab]

> For the same reason they claim that "stealth" firewalling is only "security through obscurity"

It is.

That in itself doesn't necessarily mean it can't be a useful measure, *in conjunction* with other security measures. Security though obscurity is not adequate security by itself. It can, however, be a meaningful component of an overall secure system.

Passwords are essentially a form of security through obscurity. And if that's the only kind of security you have, that's not very good security. Obscurity is really only useful when combined with other forms of security that serve to protect and preserve the obscurity. For instance, a strong password on a remote login is not by itself very secure if the password is transmitted in cleartext every time you log in. The addition of strong public-key cryptography, however, greatly improves the security. The cryptography by itself does not create security: if the system is using a weak password, no amount of encrypting it in transit will make it secure. You have to have the two together. (Even that is a simplification: there are other things you have to have as well. Not least, the systems you log in *from* must be trusted.)

Similarly, stealth firewalling *by itself* is just about useless. That doesn't necessarily mean it couldn't ever be a meaningful component of an overall secure system, but it does mean there are other factors that have to be taken into consideration as well.

Re:Uh what

[toriver]

Maybe he has spent his time working and learning instead of wasting it on Slashdot?

Re:Uh what

[Anonymous Coward]

He's that dude --> http://blogs.verisign.com/websecurity/

Re:Uh what

[Chandon Seldon]

Passwords are essentially a form of security through obscurity.

The phrase "security through obscurity" has a well established meaning in the discussion of security measures. It refers specifically to systems that are only secure if the design is not known to the attacker.

Specific passwords (or other shared secrets like symmetric keys) are not part of the design. The design merely says that you use one, not which one you use - and security of the shared secret is only based on keeping which key / password is being used secret.

Re:Uh what

[Zeinfeld]

You cracked Marc's 128-bit encryption, but your Slashdot id is 263942. Doesn't add up.

Marc's 128 bit encryption used a random seed with 24 bits worth of ergodicity. So it was only 24 bit secure.

And SSL 1.0 had no integrity protections whatsoever, which would have been pretty bad even if he wasn't using a stream cipher. So even if he used a 256 bit cipher it would have been broken.

What makes you think this is my only Slashdot id?

Oh and in response to the AC in the other thread, no my job title is not CTO but I do report to the CTO. Nor am I aware of any occasion where I have ever discussed the results of deep inelastic scattering experiments at ZEUS on Slashdot or any other forum.

Re:Uh what

[Alcoholic Synonymous]

But that was my point, actually. I said "only" security through obscurity, which it is not. It's the icing on the cake. Once you lock down a box, you ignore anything that is not relevant or needed for your purposes.

There is no reason, explicit or implicit, to allow an attacker to learn what OS you are running. It is none of their business. You have to pair apache with mod_security to turn off server tokens, but does it really matter what http server it is as long as it serves the pages properly? The idea is a holdover from the early days of the net when everyone was on the buddy system. That idea has been dead nearly 20 years now.

It's an irony that OpenBSD prides itself on spamd being used to waste spammers time and resources, but can't see the simple beauty of making a would be attacker having to actually guess what he is up against. Is it Windows 2000? Is it Linux? Is it vulnerable to this old crusty exploit, or is it up to date with all the patches? They can figure it out I'm sure, but they will have to waste time and resources to do it.

Ping me, find nothing and move on, or hit me with a shot in the dark, either way, the odds are better for me that I don't tell you anything that could help you.

Re:Uh what

[jonadab]

> The phrase "security through obscurity" has a well established meaning in the discussion of security measures.
> It refers specifically to systems that are only secure if the design is not known to the attacker.

Where do you draw the lines between the design and the implementation and the shared secret? Are the criteria that you use to determine whether a given password is strong enough for your purposes part of the design, part of the implementation, or part of the shared secret? Is what port you run the service on part of the design, part of the implementation, or part of the shared secret? If the port number is part of the design of the security system, then what about the sequence of port accesses needed in the case of port knocking? Is that also part of the design, or have we stepped over into the shared secret at that point. (If so, the design is weak, because signals analysis can determine the port sequence even if all the traffic is encrypted.)

More to the point, is which PRNG your system uses part of the design, or part of the shared secret?

You can draw an arbitrary line if you want and say, "It's okay for this stuff to be required to be kept secret, but it's not okay for this other stuff", but unless that line is drawn based on sane criteria (e.g., it's okay for the root password to need to be kept secret because with correct practices it reliably _can_ be kept secret, but it's not okay for the PRNG algorithm to need to be kept secret because it exposes information about itself through the course of normal interactions), it's an arbitrary line. Drawing that line based on something as unrelated to what's really at stake as "is it part of the design or not" is exactly the kind of fuzzy thinking that leads to bad security.

As I said, obscurity (which is just another word for secrets, really) can be an important part of a good security system, but you have to realistically evaluate the security properties of your system in light of how the various components interact. If the interactions between a given component and other aspects of your setup will compromise its secrecy, then the obscurity of that component is unreliable and must be considered as such.

A "stealth" firewall, specifically, is a form of obscurity that can be useful or worthless, depending on how it is employed, what else is going on, and what you are expecting it to do. If you are protecting a strictly client system, and *all* incoming ports are stealth, then it is potentially useful because a remote attacker who does not receive traffic from the client system has no way to know what if anything might be at that address. (What are you protecting against? As-yet undiscovered vulnerabilities in the network stack or firewalling software, perhaps.) The point is, your system is not actively disclosing the secrets, so they can actually stay secret.

On the other hand, if you have port 80 open incoming and are running a webserver that gives away that information to anyone who asks, then stealthing all the *other* ports accomplishes nothing to fifty decimal places. Port 80 is scanned regularly by, unless I am greatly mistaken, every major ring of computer criminals, both the scary knowledgeable ones and the, umm, others. If it's open, you're on their lists, and they *know* what OS you run, unless you've taken special steps to prevent them from being able to figure that out. And no, they don't have to spend extra resources to find this out; it's a sunk cost, because they already scan the whole internet every few days anyhow. Stealthing other ports to keep that information secret is like locking the car doors with the windows rolled all the way down.

Even if you've tweaked the web server to not directly disclose OS information and so forth, the protection provided is still pretty limited, because you're still going to be on said lists, and it's not exactly hard to automate a run of network stack fingerprinting against all the servers that haven't disclosed the information that's wanted

Re:Uh what

[Chandon Seldon]

Here's an easy test to see if you're dealing with a "shared secret" as the term is used in the context of secure system: If every detail of your security system - including your shared secret - is discovered by an attacker, you can easily generate a new shared secret and have all the security you had before.

Cryptographic keys, passwords, and port knocking sequences are all explicitly designed to be easily changed - in fact, there's usually a set schedule for changing them. PRNG algorithms (or any other sort of algorithm) are generally not designed to be frequently and easily changed, and relying algorithms that are only secure if kept secret is the classic example of security by obscurity.

Sure, you could probably come up with edge cases if you tried really hard - but just because I can't tell you the exact decimal representation of PI doesn't mean that it might be greater than 20.

Re:Uh what

[DNS-and-BIND]

Because people used to be able to make comments anonymously, before Slashdot started filtering them out by default. Also, a security researcher would have an interest in staying anonymous. I know I was on slashdot when it was new, and I never bothered to get an account until it became obvious that nobody was reading my comments due to the "Score: 1" threshold.

Re:Uh what

[jonadab]

> Here's an easy test to see if you're dealing with a "shared secret" as the term is used in the context
> of secure system: If every detail of your security system - including your shared secret - is discovered
> by an attacker, you can easily generate a new shared secret and have all the security you had before.

I'm not totally convinced that's entirely valid, even with a traditional password. Once a system has been compromised, you don't know what the attacker may have done that you don't know about. You can create a new password, sure, but maybe the attacker finds out what it is the first time you log in. Even if you can keep the new password secret to the same degree as the old one (and that's a pretty big "if"), what stops the attacker from repeating the original, successful, attack?

When an attacker compromises your security, I think it's important to try to understand how and why your security failed, and adjust the design of your security to (at least try to) prevent the same thing from happening again. That way the attacker will at least have to come up with a different approach next time.

> PRNG algorithms (or any other sort of algorithm) are generally not designed to be frequently and easily changed,

That's true, but it's also true (and, in my opinion, at least as relevant) that algorithms have been historically proven to be reliably impossible to keep secret.

However, the two concepts are somewhat related. The reason you change passwords periodically is precisely because that improves the odds of keeping them secret. If a given password has a complexity level such that you suspect it could be brute forced on average in ten years, and you only change it once a month, the odds that any given attacker can brute force it are still on the order of 1%, each month, which is way too high when there may be multiple attackers. So you either pick a much stronger password or you change it rather more often.

Re:Uh what

[zlexiss]

Mod parent +1 pwned!

Re:Uh what

[Chandon Seldon]

Once a system has been compromised, you don't know what the attacker may have done that you don't know about.

What I said was "If an attacker gets full knowledge of your security system" not "If an attacker breaks into (and potentially modifies) your system". For the purpose of discussion of security properties, these are very different scenarios.

That's true, but it's also true (and, in my opinion, at least as relevant) that algorithms have been historically proven to be reliably impossible to keep secret.

Right. That's why the "security by obscurity" rule of thumb arose.

Re:Uh what

[frost22]

Ooops. Sure ?

Hallam-Baker, IIRC, is the guy who managed to loose the first internet related libel suit, and he lost it against one of the worst kooks in usenet history, and,. agaian, IIRC, he lost very badly. Cost him tons of money.

OTOH, his CS credentials are fairly solid. And he made it CTO of Verisign? Sort
of interesting. OTOH his id his higher than mine, and mine's already nothing to be proud of.

All very strange...

Re:Uh what

[jirka]

I would be more impressed if he did not have any slashdot login. Having even read this discussion decreases his credibility.

So much for high security

[Eravnrekaree]

So much for OpenBSD being the highest security OS. Even if the bug is a minor one does not pose a great risk, it seems that one should still fix it to ensure the system is functions properly and as expected. To leave a security bug in place because of an assumption does not make a whole lot of sense and shows a bit of arrogance, when they could just fix it instead. It reminds me of the instance where Microsoft Windows 95 had the problem that even if the user had not explicitely made certain directories accessible via file sharing, all the server did was tell the client not to look at them, but would still let the client access them if it asked. The problem was reported to Microsoft by Samba, who pretty much displayed apathy about the matter and didnt seem to recognise it a as a security problem. The OpenBSD bug is not as severe, but when they have a chance to make OpenBSD a little bit more secure, why not take it, especially when their focus is on security.

Re:So much for high security

[norton_I]

If it isn't actually a security risk (I have no idea if it is or not), the most secure thing to do is to not "fix" it. Changing code always carries the risk of introducing security problems.

The OpenBSD guys are pretty defensive about security. If they say it is not a problem, I am inclined to believe them.

Re:So much for high security

[martinlp]

The OpenBSD bug is not as severe, but when they have a chance to make OpenBSD a little bit more secure, why not take it, especially when their focus is on security.

OpenBSD's argument is that a patch would not make it more secure... so your point is moot.

Re:So much for high security

[Metzli]

I may be wrong, but I don't remember anyone claiming that OpenBSD is the "highest security OS." The last I checked, it wasn't on the list for A1. It's likely to be one of the most secure open source operating systems, but it's by no means the ultimate.

Why this is so bad: DNS cache poisoning

[Anonymous Coward]

DNS cache poisoning

Re:Why this is so bad: DNS cache poisoning

[Anonymous Coward]

Please stop calling this "cache poisoning". It's DNS response forgery, whether the forged answer is cached or not is incidental. It could theoretically affect even a so-called "DNS proxy" that doesn't do any caching at all, although the evildoers would have to work really hard at that.

Re:Uh what ... yeah

[cloricus]

I like the part where if some company, say Apple, does fix it BSD sports fans can't automatically get the fix because, hey, the BSD license!

That's right, I'm trolling BSD users because their idea of Free Software has a flaw, and it'd be nice for them to realise it once in awhile. This is instead of their constant trolling of the GPL (and compatible) while pretending their perception is perfect. And I'm no coward in saying it.

What??

[uuxququex]

Are you really comparing OpenBSD to Windows 95? The mind boggles...

The flaw in the PRNG is not exploitable. Not unless you are root on the local machine and have the ability to stop all other processes. If you are root then there is nothing to exploit as you are already, well, root.

So perhaps you should have RTA first? Or where you in a hurry to make a post on front of the list?

Re:What??

[Anonymous Coward]

You've got it backwards.

You say "OpenBSD is secure, therefore any comparison of OpenBSD to windows 95 is invalid". The GP says "OpenBSD and windows 95 seem to be comparable here, therefore OpenBSD - apparently - is not 100% secure". A priori, the latter makes much more sense; your position can only be reasonably adopted if you already KNOW that OpenBSD is secure. Given that we're talking about a potential flaw in OpenBSD here, such an assertion would amount to circular reasoning.

You say that the flaw "is not exploitable". On what basis are you claiming this? Can you back up your claim somehow? Did you examine the source code or investigate possible attack scenarios? Are you an OpenBSD developer?

The answer to all the above is "no", of course. You do not know that the flaw is not exploitable; you merely have formed an opinion on OpenBSD's supposedly perfect security already and cannot stand the cognitive dissonance created by having to admit it might not be; therefore, you're forced to make claims such as this in the hopes that someone else who's suffering from the same problem(s) will mod you up.

But of course, that need not concern me, the GP, or anyone else - we don't care about your personal problems. All that matters to us is that until we have, at the very least, strong evidence that this flaw cannot possibly be exploited, we are going to treat it as if it can be. And even in the face of such evidence, we are still going to assert that it's better to be careful and that even a flaw that you currently believe cannot be exploited should be patched - after all, nobody is perfect.

It's better to be vigilant, and the OpenBSD developers should be the first to agree to that.

Re:What??

[Jugalator]

The flaw in the PRNG is not exploitable. Not unless you are root on the local machine and have the ability to stop all other processes. Wait.. what?

This could potentially provide a platform for attacks involving prediction of IP sequences and thus TCP data injection attacks.

Where is a local machine access required for that? It could provide attacks on the network traffic itself, by merely knowing which operating systems are involved in it.

Re:What??

[Florian Weimer]

This could potentially provide a platform for attacks involving prediction of IP sequences and thus TCP data injection attacks. Only if you disable path MTU discovery, which is a pretty obscure scenario (except for BGP peers, but there are better protection mecahnisms for that case).

Re:What??

[Anonymous Coward]

I refer you to this post.

http://undeadly.org/cgi?action=article&sid=20070725193920

Jakob Schlyter (jakob@) wrote to misc@:

        as some of you may have noticed, a new weakness in BIND 9 has
        recently been discovered. using this weakness, an attacker can
        remotely poison the cache of any BIND 9 server. the attacker can do
        this due to a weakness in the transaction ID generation algorithm used.

        when BIND 9 was first imported into OpenBSD, we decided not to use
        the default ID generation algorithm (LFSR, Linear Feedback Shift
        Register) but to use a more proven algorithm (LCG, Linear
        Congruential Generator) instead. thanks to this wise decision, the
        BIND 9 shipped with OpenBSD does not have this weakness.

        the proactive security of OpenBSD strikes again,

                        jakob

        ref: http://www.trusteer.com/docs/bind9dns.html

OpenBSD secure?!

[darkob]

This most certainly WILL have impact on OpenBSD's status as "secure" OS. Indeed, OpenBSD claims to have "proactive" approach towards security whereas this issue should and will diminish some of the OpenBSD's "security goodwill".

Re:OpenBSD secure?!

[Anonymous Coward]

I run just over 150 OpenBSD servers at work. Web servers, mail servers, DNS servers, FTP servers, you name it. I run three more OpenBSD servers at home, and my other two desktops are running OpenBSD.

They are all susceptible this "security glitch". But I'm not worried at all. The OpenBSD developers say this isn't an issue, and I trust their judgment. The fact that they've looked at this issue and determined it not to be a security risk shows to me that they're responsible and performing their craft with the utmost of care.

Re:OpenBSD secure?!

[Anonymous Coward]

Do you trust them when they say the mbuf bug isnt exploitable? You know, the one with a working exploit published?

Re:OpenBSD secure?!

[Anonymous Coward]

Really? They are human and therefore are fallible. Given that they could make use of the patches the other BSDs have written for this problem, it is just plain irresponsible not to patch OpenBSD even if they believe this is not a security issue.

Re:OpenBSD secure?!

[Anonymous Coward]

i suppose your message simply highlights your lack of understanding on the matter. and everyone else that modded-up your ignorant post.

Re:OpenBSD secure?!

[jd]

They're only supposed to be secure from external atacks, hence their animosity to mandatory access controls. The problem as I see it is that security is not an independent concept. Security does not depend on using one vector or another, one vector or a thousand, internal or external, technological or social. There are those who would argue that these are all distinct problems, but I disagree. (I'm terribly disagreeable at times....) An entity is either trusted or it isn't, and is either authenticated or it isn't. That's four possibilities, none of which refer to how those possibilities come about. But is total security possible? No idea, but if there's a weakness, it's in one of those four possibilities, NOT in the mechanism employed. If there's a flaw in the abstract, it must occur in ALL vectors in some form or other.

Re:Uh what ... yeah

[teh kurisu]

If BSD used the GPL, then Apple still wouldn't be providing a fix, because they wouldn't be using OSS at all. Neither licence is better than the other in this regard.

I don't agree with the trolling from either camp. The licence you release your code under is a matter of personal choice.

Re:Uh what ... yeah

[Sancho]

People have different opinions on how things should be. When it's their license and their code, they get to decide. Nonetheless, maybe you should contact the Open Source Initiative. They're an organization which collects licenses and "certifies" them as to their openness. BSD's license is listed as open source.

http://www.opensource.org/licenses/bsd-license.php

Re:If the OpenBSD devs say it isn't a security fla

[Anonymous Coward]

>If the OpenBSD developers say this isn't a security concern, I've got 100% confidence that they are correct.

I see you don't remember how OpenBSD developers downplayed remote root vulnerability in mbuf code, until COREsecurity gived them working exploit :].
And this is that mega randomness with what OpenBSD team was so proud :] LOL.

Re:Uh what ... yeah

[cloricus]

Because that is why they aren't using webkit, apache, samba, cups (or employ the guy who writes it), and several others in their default install.

While I would agree with you on the matter of trolling it really gets old when BSD users trumpet it constantly where-as in my experience GPL supporters tend to realise there are limitations. Of course I'm sure it is seen the same way across the bridge.

Re:Uh what ... yeah

[cmaxx]

Nuhuh. This is because the BSD license is semantically freer than GPL in precisely this case:

Apple are free to release their putative fix to the community, or not - their free choice. That's one more freedom, relative to being obliged to release any changes they make which lead to a binary release outisde of Apple, which the GPL would oblige.

There are plenty of folk who see that as a feature not a flaw.

Oh for Bob's sake!

[Chas]

When the PRNG in WINDOWS is shown to be vulnerable (because it's a actually static value), it's a horrendous problem.

But when the PRNG for a non-MS operating system is shown to have a similar (but not identical) problem, it's "irrelevant"?

Re:Uh what ... yeah

[timrichardson]

And besides, if computing moves away from code executing on local CPUs and onto central servers to be accessed by web clients (the "cloud"), than even GPL code modified by,for example, Google is not distributed, so the patches are not mandatorily available under GPL either.

OpenBSD vulnerability report

[Anonymous Coward]

When OpenBSD team receives vulnerability report they are working VERY HARD to find out how could they DOWNPLAY severity of it.
Instead of just fixing it and submitting errata.

Re:Uh what ... yeah

[aliquis]

What says Apple wouldn't release the source code of the patch just because they doesn't have to?

Re:Uh what ... yeah

[aliquis]

It's both more and less freedom, depending on if you are the developer or the user. There are benefits of both, even thought as I see the BSD alternative as more "free" even thought it doesn't guarantee the freedom.

Perception is as important as actuality

[Alain Williams]

It is not just good enough to be 'secure in the "real world"' it is also important to be seen and believed to be secure.

Can someone say how hard a fix would be ? Surely: for the sake of a bit of work they are committing a public relations blunder!

Re:Perception is as important as actuality

[the_B0fh]

Umm, that's important in corruption, but in a system, you are either exploitable, or you are no exploitable. Perception has no place in it. It doesn't matter if you are perceived either way.

Re:Perception is as important as actuality

[h4nk]

well Appendix C sorta lays it out pretty plainly and if I understand this correctly - and I may very well not - I would say the easiest fix may be to shorten the lifetime of the key used by PRNG to something incredibly short or do away with it all together.

Re:Perception is as important as actuality

[spidr_mnky]

This is OpenBSD we're talking about. They are far from number one in usage statistics, and I don't see a lot of proselytization from their camp. Their glorious leader, if you recall, was asked to leave another project because he was unbearable to work with. They implemented more secure memory functions that initially broke a lot of software. They don't seem likely to take the path of least resistance. Of course, I'm not a member of their team, but I get the idea that they focus on providing the best product possible for those who want a very secure system, not on giving out warm fuzzies. "Free, Functional, & Secure" is their mantra -- not necessarily popular.

Re:Perception is as important as actuality

[Alain Williams]

Perception is important -- most of the pointy haired types don't really understand the issues; if the competition shouts loudly with noises about ''not wanting to fix a security bug'' they will believe it.

The next thing is that anything *nix or open source is not really interested in security.

Remember that it is easier to loose reputation than to gain it.

Re:Perception is as important as actuality

[X0563511]

I think the real point here, is that the OpenBSD people don't really care what others think. They follow their own drum, for better or for worse.

Nobody forces you to use OpenBSD, and nobody prevents you from patching it yourself. They are entirely in their rights to say "No" even if it is a stupid thing to do.

XYZ Attacks were also unthinkable a while ago.

[burni]

I am sorry for this vague subject, but I can't remember the exact topics or incidents anymore, but there were numerous even mentioned on slashdot.

But I wanted to show that most of todays security threats
were first percived hard to be used or totally unthinkable, even minor security problems
which later were updated to the status of a serious threat, because the first look turned out to be wrong.

So when devellopers commit themselves to build the most secure OS, and than on the other hand show such no-interest in fixing this topic, or just review the *BSD solution and paste it into the OpenBSD sourcetree with their background, I can only say this behaviour is untrustworthy.

Re:Alternative submission

[yakumo.unr]

If flawed, predictable PRNG code is so 'irrelevant in the real world' why does even Microsoft seek to improve upon it?

"Strengthens the cryptography platform with a redesigned random number generator, which leverages the Trusted Platform Module (TPM), when present, for entropy and complies with the latest standards. The redesigned RNG uses the AES-based pseudo-random number generator (PRNG) from NIST Special Publication 800-90 by default. The Dual Elliptical Curve (Dual EC) PRNG from SP 800-90 is also available for customers who prefer to use it."

Overview of Windows Vista Service Pack 1

Though this question obviously will depend on how MS's previous PRNG implementation stacks up against OpenBSD's.

Random not just security

[jvlb]

While, understandably, the focus here has been on security, it should be remembered that random number generation is useful in other mathematical endeavors, as well. It is slovenly to just walk away from fixing it.

Strike 2, OpenBSD.

[Neillparatzo]

OpenBSD is on a fast track to losing its most favored secure OS status if they keep this up.

First they refused to implement WPA (despite the other BSDs having it), because it "doesn't provide real security" and "just use IPSEC".

Now they're refusing to address a weakness in their network stack (despite the other BSDs addressing it), again with the implication that everybody should just jump to IPSEC. What if you're in a situation where an IPSEC rollout is impractical or impossible?

Whatever happened to defense in depth? Whatever happened to "secure by default"? Whatever happened to constructive paranoia, such as randomizing of libc addresses, that was unlikely to have any real impact on security but was a nice extra, just in case? Why must I now upgrade to NetBSD to get security features that are lacking in OpenBSD? Isn't the shoe on the wrong foot?

What happened? Was there a change of management? Is OpenBSD under the thumb of a douchebag patch manager lately? Is this going to go away at some point? Those of us that sleep with OpenBSD firewalls like a gun under our pillow are taking notice.

Re:Strike 2, OpenBSD.

[the_B0fh]

And they care about your notice why?

Re:Strike 2, OpenBSD.

[Anonymous Coward]

First they refused to implement WPA (despite the other BSDs having it), because it "doesn't provide real security" and "just use IPSEC".

Umm, they're completely correct to take this stance. WPA is far inferior to IPSEC, security-wise. It's OpenBSD's job to help insulate you from insecure technologies. We could easily say, "Just because FreeBSD allows one-character passwords, OpenBSD should, too!" And you know what? We'd be wrong to think in that way.

What happened? Was there a change of management? Is OpenBSD under the thumb of a douchebag patch manager lately? Is this going to go away at some point? Those of us that sleep with OpenBSD firewalls like a gun under our pillow are taking notice.

What happened? Nothing happened. The OpenBSD team members are performing their task perfectly. They are computer security experts who have considered this problem, and found it to not be the issue that some others think it is. So they're doing the responsible thing, and not making willy-nilly changes to their codebase for the sake of a "security glitch" that really doesn't exist.

Re:Strike 2, OpenBSD.

[argiedot]

They aren't, that's what GP was complaining about.

Re:Strike 2, OpenBSD.

[Anonymous Coward]

IPSec is OSI layer three, WPA is layer two. Accordingly, they are not substitutes for each other; they are compliments.

So, OpenBSD is refusing to put a locking mechanism on the doorknob because it wants to make people use a deadbolt. Me, I'd want both; if it turns out my deadbolt had a defect and thus easily defeated, the doorknob lock would at least provide some security.

Re:Strike 2, OpenBSD.

[styrotech]

First they refused to implement WPA

From my impression that is an overstatement. OpenBSD will get WPA when someone writes it well enough for it to get in. Although the current devs don't want to write it themselves (as they don't feel they need it), they have left the door open for someone else to write it.

"doesn't provide real security" and "just use IPSEC" aren't reasons why it won't get in at all but reasons why that particular developer(s) isn't going to bother writing it themselves. OpenBSD is probably the ultimate "scratch your own itch" and "talk is cheap, show me the code" project. So far WPA hasn't made anyone in the OpenBSD community itchy enough. After all WEP still got in even though it is far less secure than WPA2 - someone wanted it enough to write it.

Re:Strike 2, OpenBSD.

[Breakfast Pants]

It isn't that they just flippantly refuse these things to be assholes, they have extremely limited resources and they have to make tradeoffs.

Re:Strike 2, OpenBSD.

[Anonymous Coward]

It may be a power thing: thinking that they can select how security should be implemented by not implementing other options. In this case choosing to not fix the PRNG, although I can't think of what they are trying to suggest by it.

This is my interpretation of what seems to be similar to what Debian was doing some time ago where there was a dispute on whether tzdata should be updated on stable: there's a point where you can't stick to what you believe to be the way you want your system to operate when those that use it have a conflicting expectation.

I'm a great fan of the FOSS life, but when it comes to fixing problems Micro$oft does have a decent approach: "Our customers have a problem, let's fix it... eventually."

Re:Strike 2, OpenBSD.

[Anonymous Coward]

read it , understand it ... then reply.

http://www.nabble.com/prng-and-a-fix-wich-should-(not-)-happen..--to15399833.html

Re:Strike 2, OpenBSD.

[smash]

Umm, they're completely correct to take this stance. WPA is far inferior to IPSEC, security-wise. It's OpenBSD's job to help insulate you from insecure technologies. We could easily say, "Just because FreeBSD allows one-character passwords, OpenBSD should, too!" And you know what? We'd be wrong to think in that way.

So if you have no ipsec available to connect to, but have WPA, and your data isn't *that* confidential that you give a crap that WPA can be broken (eg, you simply want to access a WPA protected internet service from your hotel or whatever), then you're fucked. Top work.

It's not OpenBSD's "job" to make choices regarding network utilisation for you. It's openBSD's "job" to provide a "Secure out of the box" installation. Which for the most part, it does.

I'm quite sure OpenBSD doesn't "insulate" you from SMTP, DNS, and cleartext passwords over telnet, if that's what you want to install.

Re:Uh what ... yeah

[Richard_at_work]

Webkit is LGPL, Apache is under the Apache license, Samba is under the GPL and CUPS (sourcecode copyright, company name and other tangibles) was purchased by Apple a year ago this month (as well as hiring the main developer).

Out of the four items you mention, only one is GPL. You could have done much better to suggest such examples as GCC et al.

The great thing about the BSD license, is that when people do contribute back (and they do, even big companies like Apple), you know its because they *want* to, not because they *have* to.

GPL has the same flaw, ya know.

[Animaether]

say Google fixes something in a GPLed project that they're -not- distributing. Then GPL fans can't automatically get the fix because, hey, the GPL license*!

( * which only says something about making the code, and thus the fix, available if the code, or compiled version thereof, is distributed. )

The difference is trivial, isn't it. In both cases an existing fix would not automatically be contributed back.

Re:GPL has the same flaw, ya know.

[hyc]

Yes, that's always been one of my problems with the GPL. Way back before it existed, I used to release all my freeware projects with a license clause "You are free to use this code as you see fit, but any bug fixes you make must be sent back to me for incorporation into the master source." When the GPL came around I got a lot of pressure to relicense my code, because my license wasn't "free" enough, or didn't fit some johnny-come-lately organization's definition of "free software license."

Freedom doesn't mean lack of responsibility. If you're getting a benefit from the code I write, and you find a flaw in it, I think you owe me a bug report at least.

Re:Uh what ... yeah

[maxwell demon]

Well, given that the other free BSDs already fixed it, non-availability of the source obviously isn't the problem here.

Re:Uh what ... yeah

[nurb432]

Licensing choices has nothing to do with this.

OpenBSD wont fix?

[nurb432]

"OpenBSD is completely uninterested"

What you really mean is 'Theo doesn't use this feature, so it cant possibly be important to anyone else in the world'. OBSD is a one man show.

Re:Uh what ... yeah

[Anonymous Coward]

Don't like the idea of people being free enough to do something you don't like? Ya want them just free enough to work and then be forced to let you have the fruits of that work? Simply because it "benefits" you? What are you, some kinda 21st century flower child? If you want a driver write a damn driver. And put your tin cup away.

Re:Uh what ... yeah

[molarmass192]

... and if Apple wasn't using OSS at all, I'd bet that they'd be selling quite a few less laptops and desktops. I know I wouldn't have bought three laptops over the past 2 years. I also know several people who would not have gone the OS X route. GCC / FreeBSD / GNU are very strong selling points for Apple that they didn't have with OS 9. On that note, I think you're right to a large extent, if it came down to a choice between the GPL or closed source, I have a gut feeling Apple would have tried the close route. The BSD license gives them flexibility to release source if and when they want.

How many people actually use PRNG?

[Secrity]

PRNG is used mostly by people who don't have a random number generator. PRNG is not needed by most (all?) current Unices and Linux distributions as they have a random number generator at /dev/random and /dev/urandom. Even older versions of Unix have patches that add a random number generator.

Re:How many people actually use PRNG?

[Anonymous Coward]

current Unices and Linux distributions as they have a random number generator at /dev/random and /dev/urandom.

Which in the absence of a hardware RNG, are also PRNGs.

Re:How many people actually use PRNG?

[ivan256]

Where do you think the data for /dev/urandom comes from? It's a pseudo-random number generator unless you've got a hardware random number generator, but even that probably uses a pseudo-random algorithm.

Re:How many people actually use PRNG?

[Adam Hazzlebank]

Where do you think the data for /dev/urandom comes from? It's a pseudo-random number generator unless you've got a hardware random number generator

It's my understanding that urandom often uses data from interrupts, keyboard input, device controllers etc. to increase the entropy of the random numbers it produces.

hardware random number generator, but even that probably uses a pseudo-random algorithm.

Hardware random number generators are not considered pseudo-random. As I understand it they usually amplify noise, pick up random radio interference or use Quantum random sources. In any case they should all have drivers to check the "randomness" of source. The only way they could be considered pseudo-random if, against the trend of modern physics, you believe that "randomness" does not exist and the universe is inherently deterministic.

Re:How many people actually use PRNG?

[IdeaMan]

The universe is indeed deterministic to a time traveler.

Re:How many people actually use PRNG?

[Adam Hazzlebank]

Hey! Me is that you!? I knew I'd invent time travel and get myself a better ID eventually.

Re:How many people actually use PRNG?

[IdeaMan]

Ah there you are! Hi Me! Hey you gotta get cracking on those flying cars. I'd help you out but I was too busy getting the blackjack. Boy is it fun being a time-traveling overlord. Oh and your lucky lotto number is 12-34-56-78-90.

Drop me a note some time so I can know what you're doing. It's real easy too, just make an envelope and write on it Do Not Open until 10/10/2010 and I'll be sure to look for it.
Whatever you do, stay away from the World Trade Center, gonna be some bad mojo goin down over there. Wait ... carry the three, add 2, time dialation facter 7.9, subtract 42 hmm that already happened nevermind. Well just have your papers ready to emigrate from the US, it's gonna get bad there real soon. You might want to check into going somewhere like the north pole, everywhere else is going down the tubes too. Stay off the InterTubes though, they'll get too clogged up for you to use. That and shipping your stored consciousness gets really expensive doing it that way. It's much easier to do it by shipping hogsheads filled with 150KLOC backup cells.

Haha about the lucky lotto number bit. We at the TimeTravelers club always get a chuckle when we play that one on an uptimer. In case you didn't know the Hiesenberg-EinstienClone17 uncertainty principle prevents my from giving you information that is valid for both a time and a place. But you can try heh, maybe you'll get lucky. Oh and get out of your mother's basement so I can get lucky you insensitive clod!

Re:So much for "Pro-*NIX" security perfection, eh?

[Anonymous Coward]

"The OpenBSD guys are pretty defensive about security. If they say it is not a problem, I am inclined to believe them." - by norton_I (64015) on Sunday February 10, @08:35AM (#22369090) I'm not, & here is why:

----------------

http://it.slashdot.org/comments.pl?sid=448136&threshold=-1&commentsort=0&mode=thread&no_d2=1&pid=22369078#22369102

"I see you don't remember how OpenBSD developers downplayed remote root vulnerability in mbuf code, until COREsecurity gived them working exploit :]. And this is that mega randomness with what OpenBSD team was so proud :] LOL."

----------------

Take a read of that, & the "sheer perfection" of those self same "OpenBSD guys" you speak of...

(& also, didn't Microsoft have the SAME PROBLEM, & patched it already (as regard RND generation on Windows XP/Server 2003/VISTA))?

Good Lord - don't tell the "Pro-*NIX" crowd here that, that MS did a better job of security than the BSD crowd has... after all: They might "pitch a shit fit" lol...

The truly hilarious part is watching the "local Penguins/BSD-Apple-MacOS X people" here (what I call the "Pro-*NIX" movement here @ /.) go into a 'tizzy' trying to 'explain it away' when THEIR OS' "of choice" turn up stuff that others have (mainly MS) before, & especially IF they already patched for it (MS has).

NOW, in respect of decency & fairness (no more "ribbing" on the 'Pro-*NIX' crew here on this site now):

Guys, face it: NOBODY is "perfect" - not the OpenBSD camp (or any *NIX variant) devs, OR, the folks from MS too...

This stuff is evolving guys, & thank goodness, mostly in security the past 1-4 yrs. now, & I.E.-> We are STILL in the "Wild West" days of computing & the internet guys!

(& it is GOOD that guys out there do find these things - we, as the end users, gain (as long as the dev teams concerned don't just "blow this stuff off" as the BSD folks apparently are - funny, the MacOS X folks, which IS a BSD derivant/offshoot, don't take it as "non-seriously" & intend to patch it, vs. the OpenBSD camp 'blowing it off', eh?))

Re:Alternative submission

[Zeinfeld]

If flawed, predictable PRNG code is so 'irrelevant in the real world' why does even Microsoft seek to improve upon it?

Because they have like six Turing award winners working for them including Butler Lampson? Of the top fifty people in network security you will find about a quarter work for Microsoft, more than for any other company, including IBM, RSA and VeriSign. They have the cash and they use it to buy the best.

Microsoft's problem is that you can't buy your way out of a shitty legacy code base in a short space of time.

Microsoft changed the RNG code to take advantage of hardware that provides a true random number generator. This was pretty much a no-brainer. Support for the AES modes is probably there so that they get some FIPS certification or other.

Re:Uh what ... yeah

[saleenS281]

Great argument, except none of the above are essential to their operating system, which is why they picked them up with a gpl license. It doesn't really matter if the source to any of those are shared or not.

Oh, and captain hater, last time I checked, the fix would be shared.

Re:Alternative submission

[innerweb]

which leverages the Trusted Platform Module (TPM)

I smell marketing droid oil. I do favor fixing security issues, but as soon as the TPM becomes involved, rational assumptions vanish. MS has a history of *fixing* things to include new technologies they are having a hard time pushing. TPM is a huge technology for them that they have had an incredibly difficult time pushing. Microsoft needs this technology to win for their game plan to succeed. Trusted Computing in general and remote control of customer PCs is a huge win for them for everything from piracy to open source to media. If they can lock the hardware and software together, excluding things like *nix, then they win. That does not discount the need to fix security issues, but there are other huge benefits for Microsoft to fix this issue if it utilizes TPM as the solution.

InnerWeb

Re:Alternative submission

[Anonymous Coward]

You seem to be confused, this isnt a problem with /dev/urandom, this is a "problem" with dns transaction ids. RTFA.

Of course a weakness in /dev/urandom would be critical, this non-issue is trivial at best.

Re:Uh what ... yeah

[Goaway]

Being given something is not a freedom. It may be a good thing, but stretching the definition of "freedom" to include that renders term almost entirely meaningless.

Don't conflate "things you want" with "freedom", please.

Troll? Redundant?

[Chas]

Why? I simply point out that a neighbor is partaking of the same nasty behavior he castigates me for...

Re:Uh what ... yeah

[RedK]

Apple are free to release their putative fix to the community, or not - their free choice. That's one more freedom, relative to being obliged to release any changes they make which lead to a binary release outisde of Apple, which the GPL would oblige.

There are plenty of folk who see that as a feature not a flaw. Your view of the freedom offered by the GPL is flawed my little BSD troll. How you managed to get that high of a score on your post shows how many of the little devils have moderation points today.

The GPL isn't about developper freedom, it's about the code's freedom. No matter who decides to pick up and distribute a fork of your project, your users are always sure the source will remain open if the corporate entity decides that it no longer wants to distribute its forks. Hence, they are assured that the modifications done over time are always available and can be included in the main tree of your project if need be.

There are plenty of folk who see that as a feature, not a flaw.

Re:Uh what ... yeah

[FeepingCreature]

I'd argue that while the BSD license gives more freedom to the individual user of the licensed code, the GPL license generates more "overall" freedom :)

As usual, a long-standing debate comes down to semantics.

  --feep

Theo is slow to change, but he will.

[argent]

Theo has refused to implement other 'foreign' security changes in OpenBSD when they were first introduced, then turned around and implemented them after a while. He was contemptuous towards non-execute stacks when I spoke with him at Usenix many years ago, because he was convinced OpenBSD's code review policy made it irrelevant and because no-execute didn't stop all stack smashing attacks... but OpenBSD eventually picked it up.

Basically, he's very conservative, very resistant to change, and don't forget that's one of the things that made OpenBSD what it was to begin with... but if it really matters he'll come around.

Re:Theo is slow to change, but he will.

[Anonymous Coward]

The difference is, when they aren't doing it, it's worthless, useless, and provides no real impact to security.

When they do finally figure out how to get it implemented, it's the greatest thing since pants pockets.

No "one thing" will stop everything. It's the combination of overlapping defenses that protects. Theo's attitude is not adequate defense against attacks.

-M

Code excerpt for the curious...

[davidbrit2]

http://xkcd.com/221/ Oh hush, you knew somebody would post it.

Re:Uh what ... yeah

[tixxit]

Yeah, that's true, though the FSF does provide another license to handle web services that authors can use instead.

Re:Uh what ... yeah

[someone1234]

For Apple it is a good feature, for the rest of the world it is either a flaw or they don't care.
I personally don't care :)

Re:Uh what ... yeah

[x_MeRLiN_x]

Speaking of moderator abuse, it might be healthy for you to realise that people with a difference of opinion aren't trolls.

Re:Uh what ... yeah

[Anonymous Coward]

The great thing about the BSD license, is that when people do contribute back (and they do, even big companies like Apple), you know its because they *want* to, not because they *have* to.

What freakin' difference does that make?

Re:Uh what ... yeah

[ShieldW0lf]

It's about the developers freedom and the users freedom. The developer is free of leverage, and can act as they wish. The user is free of leverage, and can act as they wish. They're not allowed to use the legal system to enforce leverage around the code, obviously. But that doesn't prevent them doing anything they wish with the code, it just prevents them being bastards via the legal system.

Re:Uh what ... yeah

[SuperBanana]

Because that is why they aren't using webkit, apache, samba, cups (or employ the guy who writes it), and several others in their default install.

....none of which touch proprietary hardware or deal with DRM.

Using hardware to assist a PNRG =!= lock-in

[SEMW]

Ummm, no. Read the GP again: "...leverages the Trusted Platform Module (TPM) when present". That means it still works without the TPM, but presumably has to use other and non-hardware sources of entropy (e.g hashes of time(NULL), thread ID, tick count, CPU performance counters, etc.).

Your assertion that using hardware to reduce the determinism and thus reduce the predictability of a PNRG must be some sort of strategy to lock hardware and software together betrays an ignorance of the problems that computer PNRGs are facing and have always faced. Read some of the other posts.

Re:Uh what ... yeah

[printman]

Um, CUPS is GPL2/LGPL2. Apple used CUPS for 5 years before they bought it...

Re:Uh what ... yeah

[larry bagina]

Is GNU a strong selling point for using *BSD? gcc, gdb, bison, bash, as, emacs, groff, make, and tar are the only OS X GNU command line tools I can find.

Re:OpenBSD is Dying

[Epsillon]

Time to start a new one. This meme got tiring ages ago...

Still Alive, BSD version, sung to the tune of Jonathan Coulton's "Still Alive" from the game "Portal," originally vocalised by Ellen McLain in character as GLaDOS. I be asserting me fair use right of parody, yarr!

This was a triumph,
I'm logging a note here: Huge success,
We had to dummynet the heavy traffic,
BSD Unix (R),
We code what we must because we can,
For the good of all of us,
Including vendors as well,

But there's no sense crying over closed source code,
You just keep debugging 'till the core dumps are old,
And releases get done,
Raymond gets a new gun,
But despite this we are,
Still alive!

I'm not even angry,
I'm being so sincere right now,
Even though we got here first and beat you,
Now you say that we're dying,
And this is the year of Linux' dreams,
As you make statistics up,
We are so happy for you,

Now these points of data made our code really shine,
And we're out of beta, we're releasing on time,
So I'm glad you think you won,
There's so much needs to be done,
But regardless we are,
Still alive!

So go post on Slashdot,
I think I'd prefer to read the lists,
Maybe you'll get your own kernel someday,
Maybe that Hurd thing,
That was a joke, ha ha, fat chance,
Anyway, this code is great,
It's so consistent and neat,

Look at me still gloating when there's -CURRENT to plan,
When it's said and done you'll know that we're the best "clan",
We are organised and clean,
We go where you've never been,
And we'll always be,
Still alive!

Believe me, we are still alive,
We're all legit now and we're still alive,
We're on the server and we're still alive,
We're on the desktop and we're still alive,
We're helping Apple and we're still alive,
We're running routers and we're still alive,
We're on your gateway and we're still alive,
We've got your e-mail and we're still alive,
And when you're dying we'll be still alive,
Still alive,
Still alive!

(I hope you bastards appreciate this; it took me ages to get it to scan properly.)

Re:Uh what ... yeah

[larry bagina]

It's not compatible with GPL 2. It's not compatible with GPL 3. The googles of the world are already using GPL (2 or 3) software and won't be affected.

Re:Uh what ... yeah

[Richard_at_work]

But then they bought it, including the sorucecode copyright - therefore my observations earlier are entirely valid, as the GPL does not stand for them in this case.

They'd more likely be used to compromise the user

[Xenographic]

DNS poisoning and the like are more likely to be used to compromise the user than his computer. After all, they can just put up their fake Bank of America clone that, thanks to poisoned DNS, is identical to the real one and steal his password.

Not everything is about compromising someone's computer.

why is this on the front page?

[Anonymous Coward]

more people use amigas than freebsd. you know it's true.

and open source is a scam. it just needs to dry up and blow away.

random vs pseudo-random?

[morethanapapercert]

Question for the cryptography slashdotters out there. I have only a superficial and mostly layman's knowledge of cryptography, so while I understand the need for random numbers exists, I don't know much about how they are created or used. I'm not clear on how it is possible for a digital machine, particularly a commodity hardware machine, to create random numbers that form the basis of seeds or simple one-time pads. It is my impression that any mathematical algorithm you can run in software is potentially guessable unless you use a truly random number at some point. I can imagine a device that perhaps listens to an analogue and random signal such as the thermal noise within the machine, cosmic background radiation or whatever, but this wouldn't be a commodity server running in a raised floor room. (Come to think of it, CMB might not be random and hence unguessable enough since an attacker can listen to the exact same random signal as your machine, if he is using the same algorithm he might be able to come up with the same numbers. {IANAA I am not an astrophysicist, so I don't know for sure, do two neighboring receivers pointed at the sky get the same signal values?}

I guess my questions boil down to this:

1) Is there a good way of generating sufficiently random numbers using cheap hardware?

2) If 1)=yes then why would anyone mess around with pseudo-randomness?

Re:random vs pseudo-random?

[SEE]

If you use the Via x86 processors, they have a genuine hardware RNG built in (which seems to be based on thermal noise), and you can buy true RNG peripherals. But pretty much nobody uses them (Via chips are too slow, peripherals are an added expense), which means most systems have to default to PRNGs (because it's marginally cheaper).

Re:random vs pseudo-random?

[SanityInAnarchy]

People have done things like adding randomness via microphone noise, but I'm not really sure how reliable that is.

The rest of it either isn't necessarily random, or isn't necessarily cheap enough / fast enough. And PRNGs can be made hard enough to guess that no one will. It's kind of like how RSA is possible to crack, if someone guesses the right prime factors, but with a sufficiently large key size, you can get to where all of the matter in the Universe, assembled into chips that vaguely resemble today's processors, will not be able to guess it before the heat death of the Universe.

Of course, if quantum computers ever scale, they change the math on that and pretty much demolish RSA, but they might also make true randomness easier.

And by the way -- IANAC -- I Am Not A Cryptographer.

Re:Uh what ... yeah

[Anonymous Coward]

BSD is freedom for the developers. Developers like the BSD license because they can do basically what they wish with the code other than claim that they wrote it.

GPL is freedom for the users. Users like the GPL because it means companies cannot distribute versions of GPL software with extra features without having to give those features back.

This has been the entire argument for the GPL from the beginning and what rms has been trying to say for the last ~20 years. He's bad at getting that particular message across because he wraps it in a rhetoric of "all or nothing".

Software freedom is better when its inalienable.

[jbn-o]

So, in other words, the grandparent poster's point is valid and the larger more important issue remains: proprietary derivatives of non-copylefted free software uses the free software community as a market instead of treating us as equals.

The great thing about the BSD license, is that when people do contribute back (and they do, even big companies like Apple), you know its because they *want* to, not because they *have* to.

Nobody "has" to under the GPL; to the degree that what you said is true, the same is true of the GPL. Statements like yours ignore all the choices that lead up to distributing source code. There's nothing in the GPL that compels conveyance. There are only conditions in the GPL that compel source code conveyance with object code conveyance. It's trivially easy to not improve GPL-covered software or not distribute the improved version. The larger issue here is whether the free software community owes Apple anything. We don't. If they want to join us and work with us, great, if not they can write their own software. The GPL helps ensure that when people and organizations convey copies of programs they do so as equals. NeXT (now owned by Apple) already tried distributing GCC derivative software without distributing complete corresponding source code when GCC was under GPLv2. It made NeXT look like an ass and put them at risk of being able to distribute GCC at all. NeXT later rectified the situation by distributing complete corresponding source code in compliance with GPLv2.

Re:Uh what ... yeah

[landonf]

Um, CUPS is GPL2/LGPL2. Apple used CUPS for 5 years before they bought it...

Prior to buying CUPS outright, Apple licensed CUPS under a non-GPL distribution license. See CUPS License Exceptions.

Re:Uh what ... yeah

[aliquis]

But with BSD I have the freedom to do whatever I want with it, with GPL the freedom of using the source code are guaranteed.

From the forum post:

[tfoss]

But it gets more interesting. Several other BSD operating systems
copied the OpenBSD code for their own IP ID PRNG, so they're
vulnerable too. This is particularly so with Apple's Mac OS X,
Mac OS X Server and Darwin, but also with NetBSD, FreeBSD and
DragonFlyBSD (the 3 latter O/S however only use this PRNG when
the kernel flag net.inet.ip.random_id is set to 1; it is 0 by
default, resulting in a sequential counter to be used instead...). This is really a ways out of my depth, but my naive understanding is that the PRNG is a problem because it is not actually random, and can therefore be predicted. Yet, the above states that the other BSDs in particular don't even use the randomization by default, and instead use the most predictable sequence possible. Am I missing something, or doesn't that mean the other BSDs are significantly more at risk (for whatever value of 'at risk' this threat actually corresponds to)?

-Ted

Re:Alternative submission

[Anonymous Coward]

The OpenBSD coordinator is an idiot who should not be speaking about domains he clearly knows nothing about. Unguessable random sources are absoultely CRITICAL to security.

Noonces, PKI, IVs for symetric and asymetric encryption, as TFA pointed out blind injection against widely deplyed Internet protocols which rely on sequences as their only means of security.

Who cares about OpenBSD anyway with coordinators like this they might as well have replied "Use Linux"

Unless it's Affero GPL3

[Anonymous Coward]

Which is why they made it.

Odd that.

Oh, and if it was BSD, they still wouldn't have to give out the code changes.

The reason why Google may want to is so that they don't have to keep putting the change back in (or check that something else changed in a new version breaks what they did).

Your point is true, but pointless.

Unless you wanted to do something down because you don't like it.

Re:Unless it's Affero GPL3

[Animaether]

I never argued with the fact that with the BSD you don't have to contribute back; that's what my parent poster already pointed out. My point isn't pointless given that the situation he describes applies just as well to the GPL, just to a lesser extent.

And yes, Affero GPLv3 would indeed make this apply to Google if they were using it as a server-side solution. But if it's in-house only - they still don't have to contribute back. If they (or anyone) develop for a specific client only, then only that client needs to get the fix (they, of course, can then choose to make it available, depending on what contract governed the development of the software itself.).

The non-Affero GPLv3, however, has no such clauses at all, and the existance of Affero GPLv3 does not change anything about the -main- GPLv3.

Point with these licenses is that if you fixed a bug in a project using them, you're not required to contribute the fix. With the BSD license this applies any time. With the standard GPL license this applies when you're not distributing the thing. With the Affero GPL license this applies when you're not distributing it and not using it as a server-side solution. In all of these cases, somebody can be sitting on a fix and whoever's project it originally was has no recourse, within the license, to have them make that fix available.

I'm not 'doing something down' because I don't like it - I'm just saying that they all have similar problems; it doesn't make it any less of a problem with BSD, but it clearly doesn't exempt GPL either (v2, v3, Affero or otherwise; short of a 'GPL'-style license I'm not aware of that explicitly states that all modifications must be contributed back, regardless of origin or purpose, period.)

Re:Uh what ... yeah

[HiThere]

Sorry, but it *IS* compatible with GPLv3. I believe that they included a special statement in the GPLv3 license that said it was, but I'd have to check that again before asserting it.

(So possibly it's the GPLv3 is compatible with the Affero license...but the resulting code must be released Affero.)

MD5

[RT Alec]

...it's not very hard to make two pieces of code, one innocuous and one malicious that both have the same MD5 hash, and it's been true for years.

I'm calling you on this claim.

Re:MD5

[beallj]

The claim is true. Wang and Yu published it in 2005.

Re:MD5

[afidel]

It's MUCH easier to pad out two small pieces of executable code to have the same MD5 then it is to inject an exploit into an arbitrary sized chunk and have it match a known hash value. That isn't to say that you couldn't have a small snippet of code embedded in a bunch of junk and have it match the known MD5, but that would be found out pretty quickly and so be of limited value. It's still easier to attack the source repository then it is to inject an exploit into a binary download with a matching MD5 hash that will fool people for very long.

Re:Uh what ... yeah

[that this is not und]

Is Apple using gmake and not BSD's make utility?

orthogonal freedoms

[reiisi]

freedom of the user, freedom of the producer

wild west

[reiisi]

I'll at least half agree with the wild west assertion.

But you get awfully excited about what is essentially another person/group's resource allocation choice.

I'm sure they'll take the exploit seriously when they see a reason to. Right now, they seem to think they have higher priorities.

Call it a different kind of race condition, if you will. But the only way to "fix" this race condition requires compromising the project itself.

They keep the core team small for a reason.

Your dollar, your time

[reiisi]

You be vigilant on the things that worry you on your dollar and on your time.

As we can see, even Microsoft can't seem to be vigilant on everything at once.

And the question to ask would be, what alternative? OpenBSD has (yet another) theoretical vulnerability. Is it one that affects the things you use obsd for?

MSWxxx has yet another real vulnerability. Is it one that affects what you use MSWxxx for?

It's better to allocate your time to be vigilant on things that matter (to you).

Re:Software freedom is better when its inalienable

[Anonymous Coward]

The larger issue here is whether the free software community owes Apple anything. We don't.

The larger issue is whether the software is restricted or not. If it is not restricted, it doesn't matter if it is Apple's customers using it or anyone else. If it is restricted, why do you call it free?

Re:Uh what ... yeah

[smittyoneeach]

The difference it makes is that you know who is respectable in the community.
The GPL is equally worthy of esteem, except the part where (for a thankfully small minority) it becomes a religion and all who've "sinned, and fall short of the glory of" the four freedoms are anathematized.
If someone wants to build a house of of highly contentious material like "ethics", then it helps to provide a fully developed ethical system in print, so we can all see how the various objects like buyer, seller, marketplace, copyright, trademark, and patent interact within that ethical system.
Just saying "those who disagree are unethical, because I say so" is just a bit too simplified.
Coming full circle, the support a company like Apple offers becomes another aspect of advertising, and the companies can be trained to see that people wanting to see the source code are not mere clowns, but actually adding shareholder value to the products, and providing splendid word of mouth advertising. All without being flogged by an idealogue.
Credit where due: we would possibly not even have this kind of discussion if not for RMS. He does deserve respect, if not agreement.

Re:Uh what ... yeah

[dadragon]

GNU Make, but they also provide BSD Make. BSD make is called "bsdmake", and GNU Make is called "gnumake" with a symbolic link to "make"

[meshach:~] dan% uname -a
Darwin meshach 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:48:21 PDT 2007; root:xnu-1228.0.2~1/RELEASE_PPC Power Macintosh
[meshach:~] dan% ls -l `which make`
lrwxr-xr-x 1 root wheel 7 9 Dec 15:08 /usr/bin/make@ -> gnumake
[meshach:~] dan%

They're doctrinaire, sure

[Theatetus]

But they tend to have a point. They are right, ultimately, that the transport level is the "correct" level for security. WEP and WPA are both, ultimately, kind of pointless in that a determined attacker will be able to compromise them. It's just that WPA prevents a large class of casual attacks that WEP doesn't. In theory, yes, someone concerned about secure network traffic will secure that traffic at the transport level -- the problem is that if you don't control both sides of the transaction, transport-layer security is often not available (eg, https://slashdot.org/ redirects to http://slashdot.org/

Re:Uh what ... yeah

[Nullav]

The great thing about the BSD license, is that when people do contribute back (and they do, even big companies like Apple), you know its because they *want* to, not because they *have* to.

What good is that, newfound brand loyalty and a shiny new pedestal to put Megacorp-X on? Really, why shouldn't a company contribute after exploiting the efforts of the crowd?

Re:Software freedom is better when its inalienable

[Nullav]

If it is not restricted, it doesn't matter if it is Apple's customers using it or anyone else. If it is restricted, why do you call it free?

Use isn't restricted, distribution is; it's everything or nothing at all.

References please? +Isn't this part.fixed already?

[olden]

Maybe I missed something but all links and references I've seen so far point back to the same paper by A.Klein, which itself only very partially quote the "OpenBSD coordinator"... If indeed Theo de Raadt wrote this (definitely plausible), why not put his name?

Also, the DNS issue is fixed in BIND 9.4.2, which is the version currently in OpenBSD's tree. I'd find it unlikely that somehow OpenBSD's developers deliberately left BIND PRNG fix out. Has anyone actually checked?

Why doesn't software trust /dev/[u]random ?

[m.dillon]

After the Nth time someone as approached me talking about flaws in BIND's random number generator I just have to ask myself, why the hell do the bind people, with no real cryptographic knowledge, think they can write their own? Bind doesn't seem to even have an option to use the OS's PRNG.

I had an interesting discussion with Amit regarding all the hacks people (including the Bind people) do to try to roll their own random number generator and it prompted me to review our own IP randomization code (and the 'off' default). After review I was decidedly uneasy about its secureness, mainly because it was trying to use an algorithmically generated cycle for a tiny namespace (16 bits, actually 15 the way it was coded). The problem with the IP sequence space is that you can't just randomize it, you also have to ensure that sequence numbers are not immediately repeated. DNS has similar issues.

I gave up trying to improve the algorithm and decided to throw in the towel and allocate 128KB of memory to do a look-ahead running shuffle of the 65536 possible sequence number using the system's PRNG. It's not possible to do better then that, frankly. We also decided to turn on ip randomization by default.

So that brings me back to the question: Why the hell doesn't bind have an option to use the system PRNG? Not all systems have a good random number generator, but I trust ours far more then the junk coded into bind. For that matter, I don't really mind if bind ate another 128K of memory to secure its own sequence space, if that is what it takes.

I know enough about cryptology to know that I am not a cryptographer. But regardless of that, I can still get a good feel for someone else's code and what BIND does scares me. The y need to change their code to default to something more secure, even if it is memory intensive. If they want to give their users the option to use the less memory intensive algorithm that's fine with me, but the default needs to be more secure.

DNS has its own design issues, but that is no excuse for software to exasperate them.

-Matt

Re:Why doesn't software trust /dev/[u]random ?

[Anonymous Coward]

After the Nth time someone as approached me talking about flaws in BIND's random number generator I just have to ask myself, why the hell do the bind people, with no real cryptographic knowledge, think they can write their own? Bind doesn't seem to even have an option to use the OS's PRNG.

Why are people approaching you on this topic, when you obviously know so little about BIND that all you can manage is an uninformed "doesn't seem to have an option"?

From the BIND FAQ:

Q: What do "no source of entropy found" or "could not open entropy source foo" mean?

A: The server requires a source of entropy to perform certain operations, mostly DNSSEC related. These messages indicate that you have no source of entropy. On systems with /dev/random or an equivalent, it is used by default. A source of entropy can also be defined using the random-device option in named.conf.

Re:Why doesn't software trust /dev/[u]random ?

[marka63]

named does not use /dev/random for ID generation.

named uses /dev/random for DSA signature generation. dnssec-keygen and dnssec-signzone also use /dev/random, when available.

The only secure method to prevent cache poisoning with any name server is to use DNSSEC [RFC 403[345]] as the DNS infrastructure could not cope with switching to TCP for all transactions.

Re:Why doesn't software trust /dev/[u]random ?

[mibh]

So that brings me back to the question: Why the hell doesn't bind have an option to use the system PRNG? Not all systems have a good random number generator, but I trust ours far more then the junk coded into bind. For that matter, I don't really mind if bind ate another 128K of memory to secure its own sequence space, if that is what it takes.

BIND uses cryptostrength PRNG for DNSSEC operations, but not for generating 16-bit query ID's (which is the topic of Amit's paper). 16 bits just isn't wide enough to care about predictability, and stub resolvers like gethostbyname() can't afford cryptostrength randomness even if it would do any good which it won't. My sympathies in this debate are mostly with Theo, since the only real fix for DNS Security is Secure DNS (DNSSEC). In response to Amit's original paper on this, I hacked BIND8 to use arc4random() for its upstream queries, and told folks who didn't have arc4random() in their libc to either get it or upgrade to BIND9.

To your question, why doesn't BIND9 have a build option to use the underlying OS PRNG (in /dev or libc or whatever), it's partly because this problem isn't solveable without DNSSEC so a better PRNG for 16-bit query-ID's is bad engineering economics, and partly because BIND9's PRNG is "good enough" for a 16-bit field and we (ISC) don't want the risk that some BIND builds will pull in really terrible OS PRNG's. Our BIND9 PRNG isn't cryptostrength... but spending more time on it won't make DNS more secure, only DNSSEC can do that. If DragonflyBSD wants to help secure the DNS, then make DNSSEC the default on all your systems, sign your own zones, and encourage your users to sign their zones. If your parent zone (.ORG, .COM, etc) won't take your DNSSEC keys, put them in DLV. DNSSEC is stuck in IPv6-like chicken-or-egg mode, and only dedicated coherent action from the F/L/OSS community has ever been able to unstick stuff like this.

But debates around the quality of a PRNG used to generate 16-bit integers are unproductive time thieves. We used to use the C "++" operator to select the next query ID, and in some ways I wish we had kept that practice rather than adding any kind of PRNG at all since it only gave the illusion of security without making query-ID guessing attacks impossible or even impractical.

Paul Vixie

highly improbable exploit scenario

[darkuncle]

http://marc.info/?l=openbsd-misc&m=120268516518434&w=2

basically, the requirements for a successful 'exploit' are a poorly-attended system without even the most basic safeguards against abuse.

but mostly, who's Amit Klein? He may be brilliant, or he may be Gobbles (or somewhere in between). I don't know - but the OpenBSD team has a history of making smart decisions and doing the kind of development that has earned my trust. When presented with a scenario I can't necessarily judge for myself, and given the OpenBSD dev team on one side and $random_guy on the other, I think I'll trust the side that's already earned my trust, until they do something to lose it.

Re:Uh what ... yeah

[JoelKatz]

If you read the paper, you'll see that intimate knowledge of the source code was necessary to discover the attack in the first place. If the source hadn't been available, it's quite likely this vulnerability would not have been discovered inside the lifetime of the code.