Date: Fri, 11 Jul 2008 11:37:00 +0200 From: "Bernhard R. Link" <brlink@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: DNS vulnerability: other relevant software * Nathanael Hoyle <nhoyle@...letech.com> [080711 05:17]: > There are only two types of "random" that I'm aware of. > Cryptographically secure, with values drawn from an entropy pool > populated by capturing some unpredictable real-world input, and not > cryptographically secure, which are seeded with a random value > (typically something like the number of milliseconds since midnight or > some such changing value) and then use a (albeit complex) deterministic > mathematical progression to arrive at each subsequent value. This is both very black-white and too theoretical to fit reality. Different algorithms are differently predictable. Also really "unpredictable" randomness is usually extremly scarce. The majority of computers has no built-in source for this, so has only very few bits. Misusing those for things where it is not necessary will cause everything more important to be less secure. (And not really make a difference in this case, as this service will also run out of randomness and either has to cease service (impossible) or fall back to some pseudo-randomness). > We can divide our attackers into two classes. Those able to see the > traffic generated by the DNS resolver request, and those not. Those not > able to see the traffic (in either direction) are not interesting for > purposes of random sequence generation analysis. Those who can are > where we must be concerned. I think there are some more different scenarios. An attacker might see only parts of the traffic (by example causing requests to his server, for example by some images embedded into a trojaned website). Here it is important that this part does not give enough information to predict other requests. > An attacker who can watch traffic can capture a > sequence of source ports used. Each one reduces the set of seed values > which would generate that sequence using the known algorithm. The > attack becomes much like attacks on wireless encryption... just > collecting packets quietly and further narrowing the possible seed > values. I do not see much point in that. When the attacker can see anything, why not just wait for the actual request and answer it? Why guess the source port if you can know it exactly? > Now, for a busy DNS server, many queries are being generated every > second, if there are many queries, I think attacking only gets harder, because guessing the order of requests gets harder to predict, adding more variables. > If there is a protocol issue (I'm > looking forward to hearing what Kaminsky has found), obviously it needs > to be addressed. I'm also looking forward to this. I was under the impression that is was common knowledg that dns is simply insecure, everyone trusting on it is insane, and security issues meaning it is easier to hijack than it should be (like dns servers accepting answers for things they never asked for and things like that). > In the meantime, I would say that > non-cryptographically secure port randomization is a band-aid on a > compound fracture. But using real entropy for port randomization even on hosts not having dedicated hardware to produce it is curing a compound fracture by amputation. Bernhard R. Link
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.