Slashdot Mirror


User: Free+the+Cowards

Free+the+Cowards's activity in the archive.

Stories
0
Comments
2,140
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 2,140

  1. Re:A double edged sword on Do Static Source Code Analysis Tools Really Work? · · Score: 1

    Maybe I do misunderstand, but as far as I know this isn't quite it. The standard way to add entropy to a pool is to use a cryptographic hash, and perform the operation pool = hash(pool + entropy). In this case, the pool started out uninitialized, so the first call to the hash function made valgrind complain even though it was harmless. Then the culprit commented out the whole pool update, thus destroying the effectiveness of the pool.

  2. Re:A double edged sword on Do Static Source Code Analysis Tools Really Work? · · Score: 1

    For example, the recent massive Debian vulnerability was caused by an overzealous developer trying to fix static analysis flags. One of these flags was valid, one was not, and removing both removed nearly all entropy from the RNG. I'm curious as to where this came from, because I'm seeing it a lot, but it's not actually correct.

    Both lines in question were equally valid. The trouble is that the lines which accessed uninitialized memory were also doing real work. The first time they were called, they would read uninitialized memory and mix the new randomness into it. On subsequent calls, it would do the same thing, but the buffer would have the previous randomness in it rather than just uninitialized memory.

    So both places were accessing uninitialized memory and were equally "wrong". The reason they were doing this was simply because it made no difference whether it was initialized or not, and thus it was easier not to initialize it.

    The correct fix to the warning would have been to initialized the buffer prior to the first access. Instead, the developer commented out the lines which accessed it, which ended up disabling the whole thing.
  3. Re:Supporting this. on Post-Quake, China Cuts Access to Entertainment Web Sites · · Score: 1

    Nothing wrong about it. Stalin did a great job of getting the entire country to work in concert doing exactly what he wanted. The trouble was, of course, that his policies were disastrous. Central control doesn't work very well because the guys at the top don't know what's happening at the bottom. So having the guys at the top make all of the people at the bottom jump to the same tune often ends in sorrow. The Soviets did a fantastic job of eliminating useful people who were considered politically dangerous, of forcing everyone to embrace Lysenkoism, and other such insanities. The result was predictable.

    There may very well be a genuine outpouring of grief but don't act like the government had nothing to do with it. The shutting down of TV stations and entertainment web sites is most definitely a government action. It's not as if they're shutting down voluntarily. The government made them shut down. China has a blatantly totalitarian government and this is just one aspect of it.

  4. Re:Supporting this. on Post-Quake, China Cuts Access to Entertainment Web Sites · · Score: 1

    Getting the entire country to work in concert is what totalitarian governments do. It's practically the definition of one. The reason the US government can't do this is because it's a free country. And yes, the things that totalitarian governments get their entire countries to work on are frequently good things. The trouble is that they make no distinction between getting the entire country to band together for earthquake relief and getting the entire country to band together to kill/imprison/reeducate everyone with the wrong ancestry/religion/politics.

  5. Re:There is no border between China and Tibet. on China to Regulate Internet Map Publishing · · Score: 1

    Merely a continuation of the same policies.

    In any case, I just think you ought to be consistent. If the US shouldn't have stuck their noses in where it wasn't wanted in the 50s, it shouldn't have done so in the 40s with Japan either. I'm sure the Japanese didn't want the US sticking their noses in China.

  6. Re:There is no border between China and Tibet. on China to Regulate Internet Map Publishing · · Score: 1

    US participation in the Second World War began with their embargo against Japan, trying to get them to stop wandering about in China murdering the inhabitants. This is definitely intervention, and of the pro-China flavor. Even after Pearl Harbor, the US had a lot of options, and certainly had no obligation to smash Japan flat and provide a whole bunch of aid to China in the process.

  7. Re:There is no border between China and Tibet. on China to Regulate Internet Map Publishing · · Score: 1

    If that conclusion to the Chinese civil war were truly inevitable then it would have happened. That's what inevitable means. The fact that it did not happen means that by definition it was not inevitable.

    As for what would have happened if the US hadn't intervened, I'd guess that large portions of China would still be brutally ruled by the Empire of Japan.

  8. Re:It's as simple as this on Woman Indicted In MySpace Suicide Case · · Score: 2, Insightful

    You make a fine point and I agree with you. I'm pretty sure that the possibility of libel charges is a big reason why news organizations use "alleged", but sometimes the result of CYA actions is something that's actually good, and I think this is one of those cases. Noble results from selfish actions.

  9. Re:It's as simple as this on Woman Indicted In MySpace Suicide Case · · Score: 1

    What the hell are you talking about? I cannot find any link between your post and mine, which makes me wonder why you posted it as a reply to mine.

  10. Re:It's as simple as this on Woman Indicted In MySpace Suicide Case · · Score: 4, Insightful

    Of course it's all "alleged". Until such time as the person is convicted, any reasonable news outlet will use the word "alleged" as a CYA measure against libel charges.

  11. Re:A great filter on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    As I mentioned in another post, "not affected" was bad wording. What I should have said is that I'm not in a position to fix any of the ways I may be affected by this, as compared to various sysadmins who are no doubt putting in a lot of work to clean up their own localized messes.

  12. Re:A great filter on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    Um, what? Read the title of the page. "Debian Bug Leaves Private SSL/SSH Keys Guessable". Debian Bug. A particular OpenSSL porting error which was only present in Debian. A seeding error which is not duplicated elsewhere. If you want to go on about how I may be vulnerable to other security bugs then fine, do so, but "it" in this context refers to a Debian bug which does not exist elsewhere.

  13. Re:There is no border between China and Tibet. on China to Regulate Internet Map Publishing · · Score: 1

    I still don't see why it matters how it happened.

    The patch of land we call "Taiwan" is ruled by one government. The patch of land we call "PRC" is ruled by a different government. Therefore, one is not part of the other. These are the facts and reality of the situation, and do not change just because you're upset at the US or whatever problems you have with it. You can say that Taiwan ought to be part of China, or it's historically been part of China, or that it's culturally part of China, but in a political sense they are two separate countries, simple fact.

  14. Re:There is no border between China and Tibet. on China to Regulate Internet Map Publishing · · Score: 1

    How it happened is completely irrelevant. The fact of the matter is that Taiwan does not fall under PRC jurisdiction in any way and is therefore a separate country.

  15. Re:A great filter on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    That's a very good point. I should have said that I have nothing to do to mitigate any of the damage, because I'm not in charge of any of the affected systems. I mostly just have to hope that none of my data has been compromised as a result of it.

  16. Re:"Funny haha" vs "funny sheesh" on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    You say, I don't care, it's not important so go ahead and fix it.

    You're pointing at the wrong bloke: I didn't say "fix it", I said "document it". I was trying to explain what happened by putting you in the place of the OpenSSL developers. The Debian maintainer proposed a completely benign fix, which they approved. He then completely botched the fix, totally destroying the security of his branch, and never told those OpenSSL developers about the changes he had made. There is simply no way to pin this on the OpenSSL developers.
  17. Re:The light dawns... and it's a muzzle flash... on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    "My code is too clever to be properly documented." Oh please. I've never seen any OpenSSL code before in my life until I looked at the diffs for this bug, and I found the code to be perfectly clear. Hashing newly received random data with the existing contents of a buffer is a completely standard cryptographic idiom.

    NOBODY is so clever that they don't need to document their code. There's no point in documenting obvious behavior.

    Well, for one thing, he probably wouldn't have screwed up... or at least when he submitted the change it wouldn't have been OK-ed by someone from the OpenSSH team, as this one apparently was. The guy who made this change never adequately explained what changes he made to the OpenSSH team. He said he was going to take out the uninitialized data access, which would have been just fine, and they took him at his word. Unfortunately he completely destroyed the behavior of this seeding function instead. If he had actually shown them diffs, or even said exactly how he planned to make his changes, they never would have gone for it.

    Think of it as nulling out object references. I say, this is unsafe, it's not nulled. You say, I don't care, it's not important so go ahead and fix it. Then you fix it by nulling out the object reference after it's assigned, but you never tell me about that little detail. That's exactly what happened here.

  18. Re:The issue is a bit more complicated... on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 3, Informative

    This has been explained elsethread, but just in case anyone wanders into this one....

    The problem is not the fact that the uninitialized memory seeding was removed. The problem is that the removal was done in an incompetent and destructive manner. Rather than remove only the uninitialized memory seeding, the maintainer managed to remove all seeding.

    Reading uninitialized memory as part of random seeding isn't very useful but it's not bad either, since at worst the data is predictable, and OpenSSL mixes it with lots of other randomness. But when you botch your change and completely destroy any randomness present in the system, this is not the fault of the software you were trying to "fix".

  19. Re:Surely this is not the only source of entropy! on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    OpenSSL uses a lot of different sources of randomness. The uninitialized data is just one source out of many.

    The problem here is not the removal of the uninitialized data source. The problem is that the removal was botched, and resulted in disabling every source.

    This is not due to a problem in OpenSSL's implementation, nor would removing the uninitialized data seeding cause any security problems. The compromise was caused by a clueless maintainer making bogus changes to code he didn't understand, pure and simple.

  20. Re:It will be fixed on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    Most users do not generate nor use ssh/ssl keys or certificates. Say what? Every time you purchase something from Amazon you're "using" an SSL certificate, and if Amazon's SSL cert was generated on one of the affected distros then your credit card and order information could be completely compromised.
  21. Re:2 years? on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 3, Insightful

    Bugs with differing severities have different priorities, though.

    If 99.9% of client code works, then an obscure bug in BSD directory traversal code is pretty unimportant. It won't affect most people, so it won't be found by most people.

    This kind of bug, on the other hand, severely harms the security of everyone using this distro. It's tricky because it's hard to tell the difference between good crypto and crypto which has a critical flaw at the beginning which makes it insecure, which is why it lasted for so long before being found. But still, one would think that crypto software would get more attention and that someone would have noticed that every affected machine is spitting out nearly identical keys.

  22. Re:A great filter on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 4, Insightful

    Your SSL-enabled web sites spent two years being vulnerable to masquerade or man-in-the-middle attacks. Your SSH servers spent two years being vulnerable to same. Your SSH key pairs spent two years being easily crackable by anyone who happened to notice this vulnerability but didn't tell the world. I'm not entirely sure, but I think that SSL and SSH sessions either to or from the affected OSes may be crackable, and if so this would include traffic that was recorded at any time during the vulnerable period and can now be analyzed using knowledge of this bug to find out what data they carried.

    This is a big deal. Maybe it doesn't affect you very much. It doesn't affect me at all, I've never run these distros. But you can bet right now that there are a lot of heavy Linux users out there going through a lot of trouble. This is going to be a bonanza for certificate authorities as everyone who generated SSL keys with these distros is going to need to purchase a new cert.

  23. Re:2 years? on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 1

    The BSD bug would cause some directory entries to be missed with a certain rare sequence of API calls. This bug causes every single private key generated with a couple of popular Linux distros to be massively insecure. You'd hope that enormous security holes would be noticed a whole lot sooner than obscure directory traversal bugs.

  24. Re:A great filter on Debian Bug Leaves Private SSL/SSH Keys Guessable · · Score: 0, Flamebait

    If you want to walk around being an insulting moron then I'd prefer you to exercise your freedom of expression elsewhere. Slashdot is a private organization and you have no right to express yourself in this particular place.

    (I have no problems with people who don't understand the problem, only with those who are militant about it.)

  25. Re:There is no border between China and Tibet. on China to Regulate Internet Map Publishing · · Score: 1

    Very good. I do my best to actually see things as they are, rather than as I want them to be, no matter how annoying the world can be sometimes.