Slashdot Mirror


Null-Prefix SSL Certificate For PayPal Released

An anonymous reader writes "Nine weeks after Moxie Marlinspike presented at Defcon 17, null-prefix certificates that exploit the SSL certificate vulnerability are beginning to appear. Yesterday, someone posted a null-prefix certificate for www.paypal.com on the full-disclosure mailing list. In conjunction with sslsniff, this certificate can be used to intercept communication to PayPal from all clients using the Windows Crypto API, for which a patch is still not available. This includes IE, Chrome, and Safari on Windows. What's worse, because of the OCSP attack that Moxie also presented at Defcon, this certificate cannot be revoked." Update: 10/06 23:19 GMT by KD: Now it seems that PayPal has suspended Marlinspike's account.

351 comments

  1. In other news... by Anonymous Coward · · Score: 4, Funny

    ...it is thought that more people are going to be using Macs' and Linux in the future.

    1. Re:In other news... by Trepidity · · Score: 2, Funny

      2010, Year of the Linux Desktop?

    2. Re:In other news... by Shikaku · · Score: 3, Funny

      2010 is the year of the phished desktop :3

    3. Re:In other news... by Jurily · · Score: 1

      2010, Year of Failed Dreams And Geeks Who Were Right But Nobody Cares.

    4. Re:In other news... by skirtsteak_asshat · · Score: 1

      No no no, it's flying cars, THEN Linux desktop. Just read Balmers blog, it answers all these questions and more. This is precisely why I deleted all my certificates, and now manually verify each site line by line in a sandboxed 16bit hex. Did you know that Paypal is actually run by a guy named Moxie Marlinspike? This is a pretty elaborate prank, obviously.

    5. Re:In other news... by __aaclcg7560 · · Score: 3, Funny

      2012, Year that no one will care about your Desktop or anything else.

    6. Re:In other news... by Anonymous Coward · · Score: 0

      We have flying cars already, but we also have an FAA, so we're stuck on the ground for the foreseeable future.

    7. Re:In other news... by melikamp · · Score: 0, Flamebait

      Fuck Macs.

    8. Re:In other news... by PRMan · · Score: 1

      ...it is thought that less people are going to be using PayPal in the future.

      --
      Peter predicted that you would "deliberately forget" creation 2000 years ago...
    9. Re:In other news... by Dersaidin · · Score: 3, Funny

      Maybe if someone could use the SSL exploit to hijack the windows update service and use it to replace everyone's windows installs with linux.

    10. Re:In other news... by Anonymous Coward · · Score: 0

      Have you ever gone back and read your own comment history? Fucking shameful.

    11. Re:In other news... by Anonymous Coward · · Score: 1, Funny

      OTOH, I don't have any Libertarians riding fireballs into my house.

    12. Re:In other news... by Jurily · · Score: 1

      We have flying cars already

      Show me one that doesn't kill your eardrums.

    13. Re:In other news... by Anonymous Coward · · Score: 1, Interesting

      But is it really 2012 in 3 years? I mean, the romans and the catholics messed up the calendar so many times... maybe we're really in the year 1809 for all we know.

    14. Re:In other news... by SignOfZeta · · Score: 0, Offtopic

      2010, the year of that win you First National Lottery of Nigeria, headquartered in an English-speaking embassy for purposes translation. To claim the money, please use our secure website [paypal.com] with your name, address, bank account information, and Social Security number to claim you're prize.

    15. Re:In other news... by Anonymous Coward · · Score: 0

      Yes I have actually. I will say my manuscript is shaping up nicely.

    16. Re:In other news... by cjb658 · · Score: 0

      Won't happen.

      I believe WU already has Microsoft's certificates installed, so there is no need for it to go download them from the internet, which is how this attack works. When the user tries to download the certificate from the internet, the attacker replaces the certificate with his own and tricks the user's browser into thinking his certificate belongs to the web site the user is trying to access.

      OTOH, Linux is vulnerable to this attack too- maybe even more so thank Windows. Windows FF users get the latest updates pretty much instantly, while Linux FF users have to wait for the update to show up in the repository, so when a fix is created, it might take longer for it to be applied to Linux users.

    17. Re:In other news... by ProfessionalCookie · · Score: 2, Insightful

      2010, the year that Windows got A LOT more expensive than Mac.

    18. Re:In other news... by wakingrufus · · Score: 2, Informative

      in general, Security patches are pushed in the repos right away, only major version changes are held off for next release.

    19. Re:In other news... by Anonymous Coward · · Score: 0

      We also have a majority of the population who cannot handle basic road navigation and interaction with other people in a 2D style. 3D, it will be much worse, especially with people falling out of the sky because they got so drunk and mashed in the throttle all the way so their vehicle stalled.

    20. Re:In other news... by Kjella · · Score: 1

      But unlike the Year of the Linux Desktop, that one comes true every year.

      --
      Live today, because you never know what tomorrow brings
    21. Re:In other news... by keefus_a · · Score: 1

      Or start using Opera.

    22. Re:In other news... by Lennie · · Score: 1

      2012 is not the end of the world, it's the end of a cycle. Yes, things change, things change all the time.

      --
      New things are always on the horizon
    23. Re:In other news... by Anonymous Coward · · Score: 0

      Macs' what?

    24. Re:In other news... by L4t3r4lu5 · · Score: 1

      They'll be waiting to hear what the then-current Mayor of London will say in the opening speech of the Olympics? Can't be as bad as Blondie's statements in Beijing... WIFF WAFF INDEED!

      --
      Finally had enough. Come see us over at https://soylentnews.org/
    25. Re:In other news... by promythyus · · Score: 0, Offtopic

      THAT cycle never ends, it will permanently be the bane all of non-single men

    26. Re:In other news... by Hurricane78 · · Score: 1

      2015, the year, where the concept of a desktop is forgotten, and everyone plays with tiny tiny colorful clickable "mobile" devices with tons of blinkenlights on them.

      At least that's what every "futurologist"* predicts, and thousands of "media" parrots of all colors croak through the ether.

      Oh, and every server will be a tiny "blade" made out of even tinier "bladelets" which itself will be made out of flat versions of those colorful clickables.

      ___
      * Astrology for scientists.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    27. Re:In other news... by init100 · · Score: 1

      while Linux FF users have to wait for the update to show up in the repository

      This is not because it's Linux, but because the browser is installed where the user does not have write permissions. If the user installs a binary Firefox release into his own home directory, Firefox is updated just like on consumer systems (i.e. where all users are administrators) running Windows. If Windows administrators install Firefox and restrict ordinary users from installing software, Firefox cannot be upgraded by the user, just like when using Firefox packaged by a Linux distributor.

    28. Re:In other news... by KDR_11k · · Score: 1

      I'd rather not, that'd hurt.

      --
      Justice is the sheep getting arrested while an impartial judge declares the vote void.
    29. Re:In other news... by characterZer0 · · Score: 1

      Parent was modded funny, but it is insightful. People will not switch to Linux, they will just have viruses.

      --
      Go green: turn off your refrigerator.
    30. Re:In other news... by sproot · · Score: 2, Funny

      Weirdly enough, Linux doesn't use the Windows CryptoAPI and therefore isn't vulnerable to this.
      Neither does FF on Windows, don't know about Opera though. Doubtless a fanboi will be along with the news shortly.

    31. Re:In other news... by mdwh2 · · Score: 1

      Or Linux. Or BeOS. Or AmigaOS. etc.

    32. Re:In other news... by CynicTheHedgehog · · Score: 1

      It will happen. 5 years ago, a family had one central PC that they all had to fight over. Now they all sit in the living room with their individual smartphones and nettops that they can afford because they are subsidized by the carrier. They are cheaper and everyone has their own device with 24/7 access, and every two years you can upgrade cheap. More than enough for text, IM, E-mail, web browsing, money management, research and report writing, casual gaming, and FaceSpace. Heck they're selling a wireless printer/scanner/fax/copier at Target for less than $100. They have NAS devices wireless interfaces, and you can plug a USB 2.0 backup drive into those. Who needs a server or central PC?

      You'll still have gamers and hobbyists purchasing PCs, but they will be more likely to be specialized high-end machines.

      On the server side you'll still have big metal, whether it's some distributed cluster or mainframes of a sort. Got to serve the cloud.

      For anyone just entering a CS/CIS program in college, smart money's on embedded programming or multi-core parallel programming on distributed/clustered systems. (And it won't be too long before someone starts sticking multiple cores in cell phones, if they haven't already...)

    33. Re:In other news... by CharlyFoxtrot · · Score: 1

      But is it really 2012 in 3 years? I mean, the romans and the catholics messed up the calendar so many times... maybe we're really in the year 1809 for all we know.

      It's all just convention anyway, if you call it 1809 you're living in 1809. I think we should do like a lot of sci-fi writers and put year 0 at 1945 AD when the first atomic bomb was dropped. Now THAT was a milestone if ever there was one.

      --
      If all else fails, immortality can always be assured by spectacular error.
    34. Re:In other news... by petermgreen · · Score: 1

      We have flying cars already
      It really depends on your definition of flying car.

      If you mean a vehicle that can both fly and drive on the road but still needs a runway/airfield to take off then those certainly exist though none have yet made it to commercial production.

      If you mean a VTOL craft that can take you end to end then small helicopters are commercially available albeit at costs that only the very rich can afford. Of course you have to find enough space to land it at both ends which can be a problem.

      If you mean a scifi-style craft that can fit into the space of a normal car, can take off and land vertically from a normal parking space and can fly without high noise levels and with affordable fuel consumption then that is much future away.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    35. Re:In other news... by petermgreen · · Score: 1

      Can't say i've seen any mobile vendors giving away/subsidising nettops. At least here in the UK they only seem interested in subsidising portable machines (both netbooks and low end regular notebooks) and you have to sign up to pretty long mobile broadband contracts to get them. Did you mean to say netbooks when you said nettops?

      IMO even if the desktop dies off in the home I doubt it will die off in the office. Portables are more expensive for a given level of capabilities, less ergonomic, more fragile, harder to service and easier to steal than desktops and I don't see any of those things changing.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    36. Re:In other news... by silly_sysiphus · · Score: 1

      Dual cores already have shown up in some phones...my Nokia E90, for example, has a dual-core ARM11. One core is assigned to telephony, the other to the "smartphone" functions. Granted, its' not an average "free on a 2-year contract" phone, but they're out there if you look.

    37. Re:In other news... by Anonymous Coward · · Score: 0

      Simple fix:

      1. Paypal blocks access from affected windows browsers
      2. Users start switching to unaffected browsers/platform
      3. Microsoft realizes this is high priority and fixes the problem
      4. Everyone is happy, for he whole 2 seconds to the next vulnerability :)

    38. Re:In other news... by CynicTheHedgehog · · Score: 1

      I'm not well-versed in the distinction between netbooks and nettops, but I have seen $200-$300 devices that are bigger than phones and smaller than laptops with and without built in 3G support.

      Laptops are approaching the price of desktops, and portability, and that's with comparable system specs. A lot of employees do little more than tinker with documents, spreadsheets, and E-mail/calendaring software, so there is no great need for horsepower. So in the office I see three types of devices: workstations (for developers/IT professionals); dumb terminals connected to Citrix servers (or similar) for stationary employees or non-personal stations (think call center); and laptops for managers, salespeople, and employees prone to frequent travel or telework.

  2. Heh... surprised? by vintagepc · · Score: 1

    Well, we can't say they didn't have enough time to at least try doing something about it...

    --
    Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
    1. Re:Heh... surprised? by commodore64_love · · Score: 0

      I don't see Firefox or Opera listed in the summary. Are they safe?

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    2. Re:Heh... surprised? by petronije · · Score: 5, Informative

      Looks like lynx (http://lynx.isc.org) is still safe.

    3. Re:Heh... surprised? by Romancer · · Score: 4, Informative

      From the article:

      Fortunately, Mozilla developers patched the hole a few days after Marlinspike's demo and Apple followed suit a few weeks later with Safari for OS X. That means if you're on Windows, the only way to protect yourself against this critical vulnerability is to use versions 3.5 or 3.0.13 or later of Firefox. At least until Microsoft fixes the CryptoAPI, whenever that may be.

      --


      ) Human Kind Vs Human Creation
      ) It'd be interesting to see how many humans would survive to serve us.
    4. Re:Heh... surprised? by Anonymous Coward · · Score: 2, Informative

      From the information I can find online, Opera does not use the affected Windows Crypto API.

    5. Re:Heh... surprised? by Anonymous Coward · · Score: 0

      Looks like lynx (http://lynx.isc.org) is still safe.

      Don't forget about links (http://www.jikos.cz/~mikulas/links/)

    6. Re:Heh... surprised? by Brian+Gordon · · Score: 2, Informative

      Don't forget about elinks (http://elinks.or.cz/)

    7. Re:Heh... surprised? by moon3 · · Score: 1

      CryptoAPI is easily avoidable, just use Unix libs for Hashing, Keys and Singins. I am surpriced that those multiplatform apps like Chrome are using this at all.

    8. Re:Heh... surprised? by citizenr · · Score: 1

      I dont think Opera uses Windows crypto API.

      --
      Who logs in to gdm? Not I, said the duck.
    9. Re:Heh... surprised? by Lennie · · Score: 2, Informative

      I have some doubts about that, even wget was not safe:

      http://changelogs.ubuntu.com/changelogs/pool/main/w/wget/wget_1.11.4-2ubuntu1.1/changelog

      --
      New things are always on the horizon
    10. Re:Heh... surprised? by maxwell+demon · · Score: 3, Funny

      CryptoAPI is easily avoidable, just use Unix libs for Hashing, Keys and Singins.

      So am I more secure if I sing myself instead of the computer letting it do for me?
      Does it matter which song I sing? I guess "ring of fire" would make a good firewall?

      SCNR :-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
    11. Re:Heh... surprised? by Hurricane78 · · Score: 1

      Or Opera, which does not use the Windows Crypto API but OpenSSL.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    12. Re:Heh... surprised? by RiotingPacifist · · Score: 1

      Moving from one framework to another might be a sensible move (it will increase overhead as it is generally better to use a systems inbuilt APIs than your own), moving from a full crypto framework to building your own system (with its own bugs) is retarded:
      *Less testing of the framework
      *Needs your maintenance
      *Comes with your own overhead (the overhead of using shared systems is pretty small)

      --
      IranAir Flight 655 never forget!
    13. Re:Heh... surprised? by commodore64_love · · Score: 1

      Text-only browsers are nice, but I wish they were wider. They are all limited to a measly 80 characters. (shrug). I bet the web browser on my C64 is safe.... mainly because the C64 is too darn slow to run exploits!

      http://www.armory.com/~spectre/cwi/hl/
      http://www.jac64.com/demos-amp-music/play-62.html (turn up the speaker) (warning: Java)

      "Hello customer support."
      "Yes my computer's telling my to press any key to continue."
      "Yes. And?"
      "My keyboard doesn't have an any key."

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    14. Re:Heh... surprised? by Dragonslicer · · Score: 1

      I was wondering why I saw a security update for wget the other day. The only thing I could think of was some kind of buffer overflow.

    15. Re:Heh... surprised? by DustyShadow · · Score: 1

      Looks like lynx (http://lynx.isc.org) is still safe.

      I'm sure all 13 users will be happy to hear that.

    16. Re:Heh... surprised? by DocHoncho · · Score: 1

      They are all limited to a measly 80 characters.

      Don't be silly, they're only limited by the width of your terminal. I'm writing this from elinks in a terminal with a width 120 and the text flows to fit the width quite nicely.

      Now if only the web wasn't so graphically oriented.

      --
      Celebrity worship is a poor substitute for Deity worship and costs more to boot.
    17. Re:Heh... surprised? by Lord+Kestrel · · Score: 1

      links scales to whatever size your xterm window is set to. Xterm (and compatible terminal emulators) have a handy little property they can pass which states the rows + columns of the current window. Applications such as links can read that property, and scale their size appropriately.

    18. Re:Heh... surprised? by moon3 · · Score: 1

      I agree that reusing some existing API is the way to do it, but I meant to use some other "CryptoAPI" that exists on Linux or elsewhere (OpenSSL?), I haven't written a word about creating their own. Also to calculate checksums, hashes or randomize keys you do not need anything platform, system or OS dependent I would presume, any such a *NIX code (already in use there anyway) should do the trick be easy to port to Windows.

  3. Yay Choices! by Anonymous Coward · · Score: 1

    Thank God I use Firefox!

    (More importantly, I have IE 8, Firefox, Chrome, and Opera all installed - that way I can use whichever one is safest each week)

    1. Re:Yay Choices! by Darkness404 · · Score: 0

      If you have IE 8 installed chances are you have Windows. Switch to OS X, Linux or another non-Windows platform and your risks of being infected will drop dramatically (yeah, it might be security through obscurity, but it works well enough not to get viruses so long as you aren't a complete idiot).

      --
      Taxation is legalized theft, no more, no less.
    2. Re:Yay Choices! by quickOnTheUptake · · Score: 4, Informative
      Using a less targeted platform is not security through obscurity, at least not in the conventional sense of the term.
      This is a nice definition:

      Security Through Obscurity (STO) is the belief that a system of any sort can be secure so long as nobody outside of its implementation group is allowed to find out anything about its internal mechanisms. Hiding account passwords in binary files or scripts with the presumption that "nobody will ever find it" is a prime case of STO.

      For shits and grins here is a slashdot feature on the topic; the first couple of paragraphs should make the usage clear. In fact he even goes on to point out that it can not be used by opensource software.

      --
      Mod points: Guaranteed to remove your sense of humor.
      Side effects may include gullibility and temporary retardation
    3. Re:Yay Choices! by Jaysyn · · Score: 4, Informative

      Or just use Firefox. Wow, that's a lot easier!

      --
      There is a war going on for your mind.
    4. Re:Yay Choices! by Anonymous Coward · · Score: 0

      Great advice! Oh, but how come my software doesn't work now and I have to plug in my wired ethernet card to get on the network? Hmm, randomly suggesting that folks whose needs you don't know or understand switch to some other OS doesn't always help anyone.

      The OP may in fact be a great candidate for Linux. Or, they may have already researched it and found their needs to be better met by Windows. You don't know as there wasn't enough information to determine that.

      I'm personally running Windows 7, Windows Vista, and Ubuntu. Never had any infections on any of them. It isn't hard to have a fairly secure Windows machine as long as you are running a current version.

    5. Re:Yay Choices! by Excelsior · · Score: 5, Insightful

      I am not a security expert, but does switching to Firefox really solve the issue? For browsing, sure. But everyone is saying this is part of the core crypto API in Windows. Certs are used in more things than just IE.

      When the app you want to install says it is signed by Microsoft, Mozilla, or Nullsoft, can you still be sure that it really is? Can you be sure the Windows Update software is actually retrieving updates without a man-in-the-middle?

      I really don't know the answers to these questions. But I would be surprised if switching to Firefox is a cure to a bug in the core Win32 apis. Helpful: yes. A solution: probably not.

    6. Re:Yay Choices! by QuantumG · · Score: 1

      I completely agree with your definition and rebuttal to the grandparent, but can I just say that STO is often used as an excuse for poor secrecy? Yeah, it's great if you can write perfect code and implement an adequate encryption standard, but that's no reason to go advertising which encryption standard you're using, unless you really have to. If someone is intercepting traffic on the wire I'd rather make them know stuff about the entropy of common encryption standards and have to guess which one it is.. and then figure out how I'm doing block chaining and which packet envelope I'm using, etc, etc. If all that is published then they don't even have to look at the implementation. By forcing them to look at the implementation you're ruling out less sophisticated attackers.

      --
      How we know is more important than what we know.
    7. Re:Yay Choices! by Anonymous Coward · · Score: 1, Informative

      I believe Firefox has its own cross-platform libraries for the functionality in question, the other browsers use the Windows libraries.

    8. Re:Yay Choices! by Brian+Gordon · · Score: 1

      You shouldn't count on the encryption method being a secret.. either the communication is secure or it's not; adding an insignificant hurdle to weed out less sophisticated attackers is pointless.

      Defense in depth means multiple layers of in-theory-solid defenses, not multiple layers of broken defenses meant to annoy attackers

    9. Re:Yay Choices! by Anonymous Coward · · Score: 3, Informative

      IIRC Firefox has its own cross-platform libraries for the code in question, which is why it isn't vulnerable like the browsers that depend on the win32 libs. Mozilla can just patch those libs whenever they want, and in this case they did so before Microsoft patched the win32 libs.

    10. Re:Yay Choices! by Anonymous Coward · · Score: 0

      Wow - a whole post without profanity or insults! OK, what did you do with real QuantumG?

    11. Re:Yay Choices! by QuantumG · · Score: 1

      adding an insignificant hurdle to weed out less sophisticated attackers is pointless.

      Huh? It weeds out less sophisticated attackers.. how is that pointless?

      Defense in depth means multiple layers of in-theory-solid defenses, not multiple layers of broken defenses meant to annoy attackers

      What's wrong with having both?

      --
      How we know is more important than what we know.
    12. Re:Yay Choices! by poopdeville · · Score: 1

      Performance losses with no real gain in security.

      On the other hand, I am not against the idea of having multiple common public key crypto systems in the wild, as long as they are each provably "hard" to solve. Doubling or quadrupling the time it takes to brute force a key is no trivial matter. On the last hand, I can do that much by adding a few more bits to my private key.

      --
      After all, I am strangely colored.
    13. Re:Yay Choices! by QuantumG · · Score: 1

      Performance losses with no real gain in security.

      So long as your definition of security is one that is non-quantitative, sure.

      If, on the other hand, your measurement of security is that none of your customers have ever been compromised using your product, I think any "hurdle", no matter how trivial it is to some attackers, can be worth it, so long as it is non-trivial to other attackers.

      --
      How we know is more important than what we know.
    14. Re:Yay Choices! by Anonymous Coward · · Score: 0

      The other two ACs didn't address the issue you raised, so I'll put it plainer terms: Assuming MS uses its own Crypto API to validate signed code (e.g. signed driver software), can this vulnerability be used to break that, too?

      I don't know the answers either, but that's a pretty scary thought, and it looks like you're the only one who has raised it here.

      - T

    15. Re:Yay Choices! by poopdeville · · Score: 2, Informative

      So long as your definition of security is one that is non-quantitative, sure.

      My statement can be quantified straightforwardly, thought it depends on the details of a specific application and the security systems it uses. Specifically, the algorithmic properties of said security systems (the cost) and an analysis of the risk the systems reduce or introduce (the gain).

      Security, much like finance, is about risk, and using effective methods to manage your exposure to risk. Ineffective methods don't reduce your exposure to risk. That's why they are ineffective.

      --
      After all, I am strangely colored.
    16. Re:Yay Choices! by QuantumG · · Score: 0, Redundant

      You're declaring them ineffective apriori. I'm asking you why you consider them ineffective.

      --
      How we know is more important than what we know.
    17. Re:Yay Choices! by palegray.net · · Score: 1

      The problem is see with this line of reasoning comes down to "who actually carries out attacks." While it's true from one perspective that reducing the ability of less sophisticated attackers to see what you're doing is beneficial, the trouble is that it only takes one "more sophisticated" attacker to create a point n' click toolkit for exploiting flaws. At this point, said toolkit will be used by hordes of kiddies.

      In the end, it's a net loss for security. I'd rather allow a bunch of smart folks to look at the implementation ahead of time (good guys and bad guys alike). At least the good guys are inclined to rapidly develop fixes for issues at that point, rather than waiting on some corporation to acknowledge there's even a problem.

    18. Re:Yay Choices! by savuporo · · Score: 1

      How about being really paranoid and utilizing all the reasonable tools at your disposal ?

      I mean, run critical checks through all the SSL/crypto layers that are available on the system. Have Botan, PolarSSL built in, optionally check with OpenSSL, CryptoAPI, if present.

      --
      http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
    19. Re:Yay Choices! by Anonymous Coward · · Score: 1, Insightful

      Can you be sure the Windows Update software is actually retrieving updates without a man-in-the-middle?

      Certainly for Vista and above, Windows Updates themselves have to be signed by a key descended from the Microsoft Root Authority (if not part of a domain with WSUS enabled). The Common Name is completely decorative on those keys; it is never checked, so this vulnerability is completely irrelevant there.

      There may be a related attack on Authenticode. This has not to my knowledge been published. Comodo also issues Authenticode keys, certainly. It should not be possible to obtain one now, however.

      Very mean-spirited of PayPal, I must say. Bad form.

    20. Re:Yay Choices! by maxwell+demon · · Score: 1

      Indeed, after figuring out that security by obscurity doesn't work, I always store my passwords in clear in a file names "passwords.txt" which I upload to all sorts of public servers, so I always have access to my passwords from everywhere. Well, I guess it's a good idea to post it here, too:

      Code on my suitcase: 12345
      Password for Slashdot: 12345
      Banking PIN: 12345
      Wikipedia password: 12345
      Password for work account: 12345
      Home computer password: 12345

      --
      The Tao of math: The numbers you can count are not the real numbers.
    21. Re:Yay Choices! by maxwell+demon · · Score: 1

      It's a net loss for security if you rely on the details being hidden. But if you hide the details, but otherwise act as if the details were public, it's a net win. After all, a system doesn't get magically less secure just because no one knows about its security. It only gets less secure if you thing you don't have to care about security because it's hidden anyway. In other words, it's the mindset which matters, not the fact that it's hidden which security system you use.

      For example, it's not easier to decrypt RSA encrypted data just because you don't tell anyone it's RSA encrypted.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    22. Re:Yay Choices! by maxwell+demon · · Score: 2, Insightful

      The point is, you get only the Firefox security after you've installed Firefox, and only assuming you've installed the real version, not a hacked one. And how do you check if you have a real version when installing your first version of Firefox? You can't check with Firefox because it's not yet installed. Checking with Firefox after the fact is pointless, too, because a hacked Firefox will certainly claim it's legitimate. Actually, even when Microsoft patches the vulnerability and you get it through Windows Update, you can't be completely sure, because after all someone might have intercepted Windows Update with a fake certificate.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    23. Re:Yay Choices! by cbhacking · · Score: 1

      Assuming Windows is actually getting the full certificate name (including the \0 and the stuff that follows) then the question is whether the UnicodeString APIs (which permit in-string NULLs) or the standard C string-handling functions (which obviously don't) are used to do the comparison. The UnicodeString functions (used in the very core parts of Windows, such as drivers, where you'll almost never see a C-style string in kernel mode) are more annoying to work with, but undeniably safer.

      This might be patchable as part of the Crypto API, but it might also be an application-by-application behavior - I don't know, my experience with Windows CAPI is essentially none. Application-by-application would make it harder to patch *everything* (and third party code would still be vulnerable) but they could still patch Internet Explorer, Outlook, Windows Update (which is a stand-alone app in recent Windows versions) and so forth.

      --
      There's no place I could be, since I've found Serenity...
    24. Re:Yay Choices! by Anonymous Coward · · Score: 1, Funny

      From this information I have already deduced your IP address is 127.0.0.1

    25. Re:Yay Choices! by sproot · · Score: 2, Interesting
      I've never really understood that comment:

      I'm personally running Windows 7, Windows Vista, and Ubuntu. Never had any infections on any of them.

      Ubuntu aside, how could you know? Do you maintain a whitelist of everything running on your PC? Do you scan for rootkits *outside your OS*? Do you maintain a list of MD5 hashes for every binary?

      Surely what you mean is that you've *never known* you had an infection.

    26. Re:Yay Choices! by Alpha830RulZ · · Score: 1

      Oh, for mod points. This is exactly on point. Security is never perfect. It's only possible to asymptotically approach perfect security. Even the canonical unplugged, powered off disconnected server behind a loncked door is vlunerable to a man with a key, an extension cord, and an ethernet cable.

      Security needs to be managed to the point where the level of risk qualified by the probable damage due to compromise is appropriate for the needs of the organization/individual affected. Additional measures beyond that point are wasteful.

      --
      I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
    27. Re:Yay Choices! by Anonymous Coward · · Score: 0

      You didn't read your parent post, did you?

    28. Re:Yay Choices! by Anonymous Coward · · Score: 1, Insightful

      So I may as well just switch off the computer and go and do some gardening?

    29. Re:Yay Choices! by cenc · · Score: 0

      check sum always before you install software. This is likly one of the core differences between MS world and Linux / open source culture. No one seems to check in the MS world that what they downloaded really is complete and original software they thought they where downloading.

    30. Re:Yay Choices! by DavidTC · · Score: 1

      Exactly.

      For example, my work laptop is encrypted with TrueCrypt.

      TrueCrypt has, on startup, a clever feature where it can pretend be a disk error. Instead of a prompt, it can say 'Missing operating system' or something. And it doesn't respond at all unless you put in the correct password. I turned this on.

      Any fool who looks at the hard drive can tell that the first sector or whatever are TrueCrypt, no matter what it says. But, at that point, after someone learns that, it's protected by actual working encryption.

      Meanwhile, some loser who steals it who boots up the laptops he steals to see if there's anything obvious on them, is going to say 'Oh, it's broken, time to reformat'.

      Yes, it's extremely unlikely that that person would actually be able to get in if, instead, they were presented with a 'Type in your password' prompt. But who knows, maybe I'm still being held at gunpoint or something and they want my password. It cannot but help.

      Using security by obscurity is stupid. Using security with obscurity is not.

      Use a well-known and tested encryption algorithm, but feel free not to label it, and to XOR the result with 'asgf12' so that someone has to figure that out and customize any cracking code to undo that first.

      And, yes, this really only applies to non-mass produced systems. Anything that could have automated attack tools written for it is pointless to hide anything.

      --
      If corporations are people, aren't stockholders guilty of slavery?
    31. Re:Yay Choices! by Anonymous Coward · · Score: 0

      So you need to confirm the checksum. To do this you go to the secure software distribution point in IE to get the checksum.... oh, that could be faked. So you go in your new install of firefox, oh, that could be pre-cracked so just lies to you.

    32. Re:Yay Choices! by spitzak · · Score: 1

      The problem is that the conversion to this supposedly wonderful "Unicode string" (really meaning a UTF-16 string) is what is truncating it. Therefore the blame lies entirely on this "Unicode string" that you think so highly of.

      I have tried to educate people before, but they are so enamored with the politically-correct idea that all langauges get equal-sized letters that they are willing to program complete moronic crap that they would never consider in any other context, just because the string is "text".

      Truth: the bytes should be compared. None of this bullshit of "converting them to Unicode" (which is really just transcribing them to a different encoding of Unicode). But Microsoft has drunk the kool aid and we are living with the result.

    33. Re:Yay Choices! by sumdumass · · Score: 1

      Heh, his passwords work too. Shit there's a lot of porn on his computer.

    34. Re:Yay Choices! by Brian+Gordon · · Score: 1

      Doubling or quadrupling the time it takes to brute force a key is no trivial matter.

      Yes, it is. It's called a single extra bit in the key.

    35. Re:Yay Choices! by Anonymous Coward · · Score: 0

      Because of network activity? Leds in the router?

  4. So let me get this right... by Darkness404 · · Score: 5, Insightful

    The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.

    --
    Taxation is legalized theft, no more, no less.
    1. Re:So let me get this right... by Anonymous Coward · · Score: 3, Informative

      Actually, this attack has been known a lot longer than that.

      I'm really glad the security product we developed uses OpenSSL even on Windows. The MS Crypto API was greatly desired at the time because it made the binary distribution a lot smaller. Originally everything was developed using OSSL because our stuff is cross-platform. Good thing we never found the time to switch over to CAPI on Windows.

    2. Re:So let me get this right... by mister_playboy · · Score: 1

      Perhaps it's a bit like being a crowd and someone gets shot... everyone knows an ambulance needs to be called right away, but they stand there looking at each other thinking, "should I make the call?". Diffusion of responsibility?

      --
      Do what thou wilt shall be the whole of the Law ::: Love is the law, love under will
    3. Re:So let me get this right... by Korin43 · · Score: 4, Interesting

      But it's pretty clear who's responsibility it is. Microsoft needs to update the Windows Crypto API. Mozilla products are already patched.

    4. Re:So let me get this right... by Anonymous Coward · · Score: 2, Interesting
    5. Re:So let me get this right... by Anonymous Coward · · Score: 0

      Well on the bright side, when Microsoft gets around to issuing a patch, everything that uses the API gets fixed, right?
      It seems like a pretty good idea except for the whole closed-source reliant-on-a-single-notoriously-slow-and-insecure-vendor issue. Even so, having to wait for one software vendor to take action beats having to wait for all of them.

    6. Re:So let me get this right... by bertok · · Score: 5, Interesting

      The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.

      The problem is that this is not just some buffer overflow where you can replace single function call with an equivalent function call that does a safety length check. Security holes that depend on '\0' characters in strings exploit a systematic flaw in the Windows API design: the mix of two entirely different and incompatible types of strings all over the place. The 'native NT' API uses Unicode strings with an explicit length, but the Win32 API and C/C++ libraries usually use null-terminated strings. The dirty compromise is to use null-terminated strings together with an explicit length. Naively, one would think that this is now compatible with both, but it isn't - the NT API strings are a superset of the C-style API strings, because they can contain \0 characters, which the latter cannot handle.

      This is a glaring flaw, has been known for many years, and will probably never get completely fixed. The SysInternals guys wrote a nice article about it once, I think, but I can't find it any more. It's lost in the mists of time. It's been exploited repeatedly too. You can create files and registry entries with \0 in them, and then none of the user-mode tools will be able to modify or delete those, including Explorer and the command-line tools. Viruses and other malware make use of this 'feature' often.

      What really shits me is that Microsoft hasn't learned a thing. They talk big about security, but it's just talk. For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.

      If Microsoft can sit on a related security holes for years, don't hold your breath for a patch for this one. Even if they do fix it, I suspect they'll do something half-assed, like create a patch for IE only, instead of the cryptographic subsystem as a whole.

    7. Re:So let me get this right... by QuoteMstr · · Score: 5, Insightful

      All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.

      To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.

    8. Re:So let me get this right... by Anonymous Coward · · Score: 0

      As another reply stated, this is something that can't be readily fixed. There are legitimate cases where you want to output raw HTML from the database. Blindly encoding data is bad. A better option would be a flag to the bind command that specifies whether to encode the data. You could even argue for a flag in web.config that sets the binding to encode by default, and you have to choose to display the data unencoded.

      A blanket statement that all "ASP.Net application are ripe for exploits" is naive.

    9. Re:So let me get this right... by nametaken · · Score: 4, Insightful

      For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks.

      I would be pretty upset if everything I pulled from DB was automagically HTML encoded. I protect against XSS where it needs to be done. There are places where HTML encoding your data would not work. I do, however, always use parameterized inserts to protect against sql injection on top of an appropriate string cleaning function. Few things aggravate me like shitty ad-hoc inserts and the absence of string cleaning tied to a client-driven interface.

    10. Re:So let me get this right... by Jaime2 · · Score: 1, Informative

      I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.

    11. Re:So let me get this right... by Anonymous Coward · · Score: 0

      "All of the data binding controls fail to properly HTML encode strings coming from a database."

      I think this is incorrect. In-line code statements like will not be automagically encoded. As mentioned, this would prevent needed functionality.

      However, if you bind to the Text property of an ASP.NET control such as asp:label, it will be HtmlEncoded for you. Likewise for textfields in gridviews and such.

    12. Re:So let me get this right... by andymadigan · · Score: 3, Informative

      In fact, most SDK's out there would likely have a similar "flaw". In Java land you need to do the escaping yourself, and there isn't a built-in function to do XML or HTML escaping. You just need to know to handle it.

      --
      The right to protest the State is more sacred than the State.
    13. Re:So let me get this right... by Anonymous Coward · · Score: 0

      "You can create files and registry entries with \0 in them, and then none of the user-mode tools will be able to modify or delete those,"

      None of the *STANDARD* user-mode tools, yes. But there's a SysInternals tool which can nuke 'em.

      (As for the ASP.Net issue, yeah well, whether to HTML Encode should be a property of the data-binding. It's sometimes approprate and sometimes not. Same as you may want to bind a 'decimal' to a label, but you want to control the formatting so it looks like a currency value - whether to HTML Encode should be set likewise.)

    14. Re:So let me get this right... by techeddy · · Score: 2, Insightful

      Actually they have addressed the HTML encoding in ASP.net 4.0: http://haacked.com/archive/2009/09/25/html-encoding-code-nuggets.aspx Although I agree it has taken quite a while, but sometimes one does need to output with and without the encoding, so I find it nice to have an explicit and easily identifiable way to do both.

    15. Re:So let me get this right... by goofy183 · · Score: 2, Informative

      True but the core Java language doesn't ship with any nice HTML widgets. I believe JSF either does escaping by default or at least has a single app-wide setting to enable it by default. The Spring MVC framework has similar options, where with one line I can enable XML and JS escaping in all content written out by UI components. Being backwards compatible is one thing but not having an option to do default escaping is just opening your developer base up to all sorts of issues.

    16. Re:So let me get this right... by QuantumRiff · · Score: 4, Interesting

      I have never understood that for years, you have been able to create a folder with a space at the end of its name in a script. Try, just try, to delete that folder.. You can't create it in explorer, you can't delete it in explorer.. in fact, the only way to fix that I have found, is hope to god its a long file name, drop to a command prompt, and delete it with "Del folder~1"

      Years and years...

      Speaking of which, I got to try that in server 2008, and Windows 7.. Its a fun way to use 3 lines of script to really piss off your IT co-workers...

      --

      What are we going to do tonight Brain?
    17. Re:So let me get this right... by symbolset · · Score: 1

      you can't fix that problem and preserve backward compatibility.

      And we all know that backward compatibility is the sacred cow that trumps even rudimentary security, right? Right?

      The attitude behind your comment is the reason why Windows will never be suitable for any business or private purpose. It's not uncommon, though. You have many a kindred soul in Redmond, Washington.

      --
      Help stamp out iliturcy.
    18. Re:So let me get this right... by herojig · · Score: 1

      Maybe they did plan it...nothing better to get users to another OS then to scare the bejesus out of them re: their PayPal accounts. Thx /., where "who knows if any of it is true."

      --
      I think therefore I can't be ~TTNH
    19. Re:So let me get this right... by cjb658 · · Score: 1

      All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.

      To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.

      Compatibility is Microsoft's bread and butter. Case in point: Linux netbooks. Why were so many of them returned? "I can't play my Windows games? OMG WTF BBQ!"

    20. Re:So let me get this right... by aztracker1 · · Score: 1

      A better question, why are you allowing input into your database that has such crap in it... Not checking the input on an app is probably more serious than unchecked output.

      --
      Michael J. Ryan - tracker1.info
    21. Re:So let me get this right... by bertok · · Score: 2, Insightful

      All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.

      To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.

      There's no backwards compatibility, ASP.NET was a completely new framework, written from the ground up. It should have done escaping correctly, right from the start. Ideally, it should be a flag that you can toggle on and off on the level of individual text fields, controls, or a whole page, and the default should be safe.

      Storing HTML in databases is one thing, and there are controls for emitting such data, such as XML, Literal or Placeholder controls, but that's a special case where a page is assembled from HTML fragments, which is actually relatively rare(*). The common case is a simple text field bound to a database column such as "user name", or "product name". There is just no good reason to allow arbitrary HTML in all database columns that are potentially user writeable. This is how you end up with shit databases that have encoded characters like "&" in them, which breaks sorting, comparisons, and non-HTML applications such as reporting engines.

      Oblig XKCD: http://xkcd.com/327/

      (*) at least it SHOULD be rare, because it totally breaks the separation between UI, Code and Data, by mixing all three together into one huge mess.

    22. Re:So let me get this right... by Anonymous Coward · · Score: 5, Informative

      I have never understood that for years, you have been able to create a folder with a space at the end of its name in a script. Try, just try, to delete that folder.. You can't create it in explorer, you can't delete it in explorer.. in fact, the only way to fix that I have found, is hope to god its a long file name, drop to a command prompt, and delete it with "Del folder~1"

      Well, the documentation for Windows Explorer specifically states that it may not support all the naming conventions of the underlying file systems. Of course, it would be entirely reasonable to expect it to fully support the naming conventions of any Microsoft file system, but MS seems to operate under an unusual definition of "reasonable"...

      You don't need a script to create such folders, just the command prompt. This will work just fine: mkdir ".\Space \". Even better, dir /X may fail to reveal this as a long filename (by definition, any filename containing a space is a long filename even if it's eight or fewer characters in length), in which case there's no way to use dir to make it obvious there's an abomination in the list of folders.

      Note that mkdir "Space " won't give you the trailing space in the folder name, at least not on anything earlier than Vista or 2003 (never tried this trick on anything after XP). Similarly, rmdir "Space " fails to remove the directory, but you can remove it with rmdir ".\Space \".

      File this under "Stupid cmd.exe tricks".

      Speaking of which, I got to try that in server 2008, and Windows 7.. Its a fun way to use 3 lines of script to really piss off your IT co-workers...

      Heh, create three sibling directories named "stuck" where they have one, two, and three trailing spaces - then sit back and watch the consternation. It will look like there are three folders with identical names under the same folder (impossible!), and none of them can be deleted with Explorer. Pure, evil fun.

      - T

    23. Re:So let me get this right... by bertok · · Score: 3, Insightful

      I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.

      Well, I just tested it with 3.5, and it's still just as broken as when I first tried it with 2.0.

      First of all, "div" and "span" aren't controls at all, but are simply markup elements, and neither support data binding (which is what I was talking about), and neither do any kind of encoding at all, so I think you might be missing my point entirely. Also, "Label" is not that rare - it's the default control inserted by the GUI designer in Visual Studio if you bind a text field in a FormView, and as you noticed, it fails to encode.

      Second, while some controls do perform encoding, this only works sometimes, usually if the target control is a "Literal", or effectively the same (e.g.: If a Literal control is generated by a data bound control as a child control). As far as I know, the Literal control is the only control that has a "Mode" property that can be used to toggle HTML encoding modes, so most other text fields are not encoded.

      For example, if you bind the "Text" property of a HyperLinkField of a DataGrid, then no HTML encoding is done, and no encoding options are available. The only option is to do a manual bind to a code-behind method that performs the encoding for you.

      What particularly shits me is how random the encoding is. Sometimes it works (literals), sometimes it doesn't (hyperlinks), but then sometimes it randomly works again, such as the Alt text of Image fields. It's not documented either!

      Is this the quality and attention to security you'd expect from the world's biggest software company? Random, unpredictable, undocumented, insecure behavior in their flagship web framework? Really?

    24. Re:So let me get this right... by bertok · · Score: 1

      For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks.

      I would be pretty upset if everything I pulled from DB was automagically HTML encoded. I protect against XSS where it needs to be done. There are places where HTML encoding your data would not work. I do, however, always use parameterized inserts to protect against sql injection on top of an appropriate string cleaning function. Few things aggravate me like shitty ad-hoc inserts and the absence of string cleaning tied to a client-driven interface.

      Nobody said that you'd be forced into HTML encoding everything, always. It should be an option that can be toggled, and it should be available on every data bound field, and it should be on by default. Turning it off should be simple, just set a flag. Note that the asp:Literal control has just such as flag ("Mode"), but AFAIK, it's the only control that can toggle encoding.

      The drag & drop designers in VS do the wrong thing by default, especially for DataGrid and FormsView templates. Even the examples in MSDN are full of technically incorrect examples.

    25. Re:So let me get this right... by bertok · · Score: 1

      Actually they have addressed the HTML encoding in ASP.net 4.0: http://haacked.com/archive/2009/09/25/html-encoding-code-nuggets.aspx

      Although I agree it has taken quite a while, but sometimes one does need to output with and without the encoding, so I find it nice to have an explicit and easily identifiable way to do both.

      Interesting, but it only seems to solve encoding issues of strings returned by in-line code, not data binding, which uses <%# ... %>.

      Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.

      This is what I mean when I say Microsoft's attitude to security is still half-assed.

    26. Re:So let me get this right... by Anonymous Coward · · Score: 0

      What about the 128 character (IIRC) 'limit' on drive:path+filename 'URL' length in basically all of Windows UI tools and so on.

      At the core IIRC NTFS and their UNC file system API has supported MAX_PATH length file / directory / entity names for over a decade, and MAX_PATH is at least a somewhat reasonably long (for the time) 32768 or so characters. So one would think "oh! good! Beyond Win98 supports NTFS, long file names, and there will be no problem having files / paths many thousands of characters long!".

      But for some INEXPLICABLE reason they BROKE the UI tools like Windows Explorer et. al. to have a MUCH shorter 'limit' of something like 128 characters before they start breaking in unexpected and fatal ways. I believe some of their higher level (non UNC? non UNICODE?) file system APIs also have this limitation, and thus the limit is probably prevalent in most any WinForms / MFC application, I haven't even checked WPF/CLR but it wouldn't surprise me if those were broken too.

      Beyond the sheer incompetence of that the additionally infuriating thing is that it is sort of easy to accidentally exceed those limits by doing normal things in file explorer like file/folder renaming, drag/drop copy/paste move something, etc.
      e.g. You can have it bomb anytime you copy/move something from a short path prefix location like "C:\stuff\..whatever..semi-long..stuff..here" that would be OK originally to a longer place like "C:\MyStuffCopiedFromTheLaptop\stuff\....whatever...." suddenly you either get a fatal copy/move error in explorer UI.
      But if you were to just, say, rename C:\stuff to C:\MyStuffCopiedFromTheLaptop it probably actually WORKS and then you end up exceeding the limit down the chain of subsidiary folders which then you'll no longer be able to access / manage properly.

      It isn't even uncommon to exceed this limit without going more than a level or two deep, e.g. I downloaded some MP3s from a major music etailer which were sensibly set to have file names that indicated the song name and artist and track number, and out of one album a couple of them were too long right from the start even when put in a short prefix location like c:\music or whatever.

      How the frak are we supposed to keep things ORGANIZED and CATEGORIZED on TERABYTE sized hard drives if we can't even include things like author name, company name, date string, site name the download came from, title of the book, title of the music, or whatever into the folder tree / file naming; doing so you very commonly exceed the soft limit on the length and thus make the whole Windows GUI effectively useless for file / folder / content management & organization.

      They effectively need to switch away from letting users pick the actual filename as the file system sees it and just start storing a database of arbitrary length / type metadata like URL, Author, Publisher, GPS coordinate, Project name, whatever associated with each bit of information and have the tools for searching / selecting / categorizing / copying become of the nature of a desktop database backed search enging. Maybe they were heading there with WinFS but it utterly failed to manifest in time since this has been overdue since Win98 days.

      At a MINIMUM they certainly need to make sure all their UI and command line tools can handle effectively unlimited path lengths, and if there's going to be an error it should be from the backing FILESYSTEM hard limit and NOT the UI tools's limit, even moreso considering that maybe you'll be manipulating files over a NAS or internet site which may not have even the FAT/NTFS at all.

      Also who keeps deciding that these "file open", "file save" dialogs that are typically TINY and typically non resizable and often don't even have the full "explorer" like functionality are acceptable? If I've got a terabyte drive or whatever, how about a system / toolkit default file open / save control that can open a LARGE window complete with a search box, a "recent..." list and path favorites/bookmarks and so on, given that I'll probably have numerous fixed and removable drives, stuff organized several levels deep, etc.

    27. Re:So let me get this right... by Anonymous Coward · · Score: 0

      You're full of it, at least on the Windows 7 part. Tested in RTM build - it has an amazing feature in Explorer called the "delete" key that deletes objects, even folders with a space on the end! Amazing what they dream up these days.

    28. Re:So let me get this right... by fluffy99 · · Score: 1

      So when OpenSSL has new vulnerabilities found, how does your program get updated? At least using the MS API it will get fixed eventually.

    29. Re:So let me get this right... by rodgster · · Score: 2, Interesting

      Wow.

      "not technically feasible" to patch at least XP 64 bit which was release after 2003 32-bit server and before 2003 server 64-bit. I thought the code base was really similar. Especially since it uses the same Service Pack (WindowsServer2003.WindowsXP-KB914961-SP2-x64-ENU.exe)

      General Availability Dates from Microsoft

      Windows Server 2003, Standard Edition (32-bit x86) 5/28/2003
      Windows XP Professional x64 Edition 4/24/2005
      Windows Server 2003, Standard x64 Edition 5/28/2005

      This cannot be anything less than a ploy to kill XP (and 2000 server) and bring on the new era of Windows Play Skool Edition (Windows Visa 2009 aka Windows 7)

      --
      Who will guard the guards?
    30. Re:So let me get this right... by Longinus00 · · Score: 1

      NTFS-3G should delete that folder (and make it) with no problem.

    31. Re:So let me get this right... by MattskEE · · Score: 1

      It's remarkable that a flaw like this still exists. Well I take that back... it's entirely unsurprising, I just got caught up in the excitement that Windows 7 is going to be better than Vista and forgot to lower my expectations.

      I tried this under the Windows 7 RTM and found that it still works, although interestingly enough, if you do it from a batch file, then you receive the error: "A subdirectory or file .\dirname(spaces) already exists.", where it has the name of the directory you made as well as the number of spaces that you put after it.

      Curious that it checks for a batch file but not the command prompt... perhaps they assume you can trust the latter but not the former. You can't trust either, but the flaw shouldn't exist in the first place.

      (and sorry I'm removing my positive moderation by posting)

    32. Re:So let me get this right... by l0b0 · · Score: 1

      Just a side note about how they handle file names: While bulk renaming files on an NTFS drive in Linux, I ended up with some file names having a space at the end. Windows (XP) Explorer was unable to delete or rename these.

    33. Re:So let me get this right... by shutdown+-p+now · · Score: 1

      I agree that it was a screwup in ASP.NET 1.0, but it's of a kind that you can't really fixed - at least some API clients are going to see it as desired behavior and start using it all over the place, yet others will just sigh and encode explicitly... and now when 2.0 comes out, if you try to change it, it will break a lot of code out there.

      There's a lot of similar crap in PHP for the same reason.

    34. Re:So let me get this right... by mpe · · Score: 2, Insightful

      Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.
      This is what I mean when I say Microsoft's attitude to security is still half-assed.


      Or rather that's their attitude to standards. With the security issues being one of the consequences.

    35. Re:So let me get this right... by biobogonics · · Score: 1

      I have never understood that for years, you have been able to create a folder with a space at the end of its name in a script. Try, just try, to delete that folder.. You can't create it in explorer, you can't delete it in explorer.. in fact, the only way to fix that I have found, is hope to god its a long file name, drop to a command prompt, and delete it with "Del folder~1"

      This type of bug goes back before that. Under CP/M, the console command processor converts all commands to upper case, so ERA filespec will not delete a file with lower case characters in its name. On the other hand, MS-BASIC does not upper case any filenames used in OPEN statments, etc. So the easiest way to remove such a file is to get back into BASIC and KILL it.

      I think MS-DOS is smart enough to fix this at the OS level.

      Some CP/M comands create a space filled filename + extension if you omit a filename. But a *. wildcard will work there.

      In a similar vein there are exploits that involve using "special" characters that look like normal characters, but aren't.

    36. Re:So let me get this right... by maxwell+demon · · Score: 1

      I guess most Windows games won't work on Windows netbooks either.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    37. Re:So let me get this right... by TheLink · · Score: 1

      It's not technically feasible because whenever the developers try to patch it, chairs keep intersecting their heads.

      --
    38. Re:So let me get this right... by NSN+A392-99-964-5927 · · Score: 1

      9 weeks is the time it takes lazy system admins to recover from drinking too much coffee and eating donuts before they they can function. There are too many unmotivated people working in IT and they are in no hurry to patch things. Remember don't do today what you can put off until tomorrow.

      --
      All cows eat grass!
    39. Re:So let me get this right... by bertok · · Score: 1

      Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.

      This is what I mean when I say Microsoft's attitude to security is still half-assed.

      Or rather that's their attitude to standards. With the security issues being one of the consequences.

      Exactly. One of the side-effects of incorrectly encoded output is that some webpages will not be 100% valid XHTML, because they will contain invalid character sequences. This is particularly nasty, because it will usually validate, possibly even pass QA tests, but then when some user adds some crap to a field somewhere, then XHTML compliant browsers will simply refuse to show you the page with an "invalid markup" error, or similar.

    40. Re:So let me get this right... by Anonymous Coward · · Score: 0

      Actually, Mozilla uses their own Crypto API (you may remember the old story from a few months ago about Firefox 3.5.0 taking forever to start on Windows machines). They inherited it from Netscape and never switched to anything else.

      (The library is called NSS and is available for separate use if anyone cares)

    41. Re:So let me get this right... by cbhacking · · Score: 1

      I suspect that if/when (hopefully when) this gets fixed, it will be fixed across all of the Crypto API. Part of the problem may be that the original CAPI is mostly deprecated now; it's present and theoretically supported for backward compatibility purposes, but the Cryptography: Next Generation API (CNG) is slowly replacing it. CNG already provides the majority of CAPI's functionality (plus a lot more) and I've heard that when they finish it, they'll deprecate CAPI and route the calls through CNG instead.

      Unfortunately, I have no idea when this will happen. I would have thought Win7 and/or Vista SP2 would be the logical milestone (CNG has been present since Vista RTM, although MSDN mentions improvements that require SP1 or Win7) but it seems like that didn't happen.

      Mind you, I have no idea whether CNG is vulnerable to this exploit as well. I've spoken to people who work on CNG and even specifically on the public key infrastructure (which handles certificates), and none of them mentioned it - but neither did I. I'd expect there to be people who are still responsible for maintaining the legacy CAPI, though...

      --
      There's no place I could be, since I've found Serenity...
    42. Re:So let me get this right... by bertok · · Score: 1

      Define "crap".

      The first ASP.NET site I developed was an internal engineering timesheet app for an IT company. It was standard practice to cut & paste scripts and code into the "notes" field for other engineers to reference later. The default ASP.NET behavior is to DENY such form submissions, which is just retarded, as code in a text field is... still text.

      I had to turn the 'security check' off, because if you use parameterized SQL statements together with correct use of HTML encoding, then scripts or code in text fields presents zero risk, but Microsoft's dirty hack of a security check breaks basic functionality. It randomly causes actions to fail with a security error, when nothing other than text manipulation is going on.

      Think about how pathetic that is: Would you expect, say, Notepad.exe to give you an "Access Denied" error message if you used it to edit a javascript file?!? Would you ship a user application that as a feature throws meaningless messages in the face of the user if they accidentally enter some magic sequence of characters?

      At first, I thought ASP.NET was nice, but my opinion dropped several notches when I saw this config option: PagesSection.ValidateRequest Property

      I love the blurb: "...determines whether ASP.NET examines input from the browser for dangerous values" (emphasis mine). Are you kidding me? It's text! Microsoft considers plain text dangerous now? What next? Threatening colors? Risky sounds?

      The fact that there's a config entry like that at all is just sad beyond words. It tells me that Microsoft so utterly failed to get ASP.NET right, that they had to layer a filthy hack on top to make it the slightest bit secure.

    43. Re:So let me get this right... by cbhacking · · Score: 1

      Seems to me that a really short script or C file would do the trick...? I mean, if you can create a script that creates it, deleting it shouldn't be hard. What I'm seeing is that the CreateDirectory() function accepts names with un-trimmed whitespace, but that the Windows shell proams automatically trim names anyhow.

      Still damn silly. I mean, I can see why they wouldn't WANT an un-trimmed name, but you'd think they'd make it reasoanbly easy to delete if one got created. Win32 programs generally ignore filesystem case sensitivity too, but if you create two files with the same name but different case (using something like the POSIX subsystem, which allows this), Windows will cope fairly well.

      --
      There's no place I could be, since I've found Serenity...
    44. Re:So let me get this right... by bertok · · Score: 1

      Yeah, this turns up all the time in real-world scenarios.

      A common case is accessing things via network shares, as it adds a prefix. In particular, DFS adds a very long prefix, such as: "\\mydomainname\dfsroot\share\...".

      If you have a multi-domain environment, then you often need to use the FQDN of the domain name instead of the short alias, which means that I've seen 60-character prefixes in real-world scenarios. There goes half your path quota!

    45. Re:So let me get this right... by Inda · · Score: 1

      We used to do something similar on open FTP sites. No one could delete your warez, which was handy after you'd spent an hour uploading a 10mb file. God damn deleters!!!

      You kids and your torrents are spoil these days. And if you must walk on my lawn, please mind the gnomes.

      --
      This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
    46. Re:So let me get this right... by Anonymous Coward · · Score: 0

      Random, unpredictable, undocumented, insecure behavior...

      Actually this is exactly what I'm expecting from that company, which is why my development workstation is a Un*x one since last century and which is why for all the "media" stuff (Skype, iChat with family overseas, watching family movies, etc.) I own a Mac Mini.

      That's also the exact reason I made my entire family switch, everytime one member had to buy a new computer, to Apple.

      Life is good for me and for them :)

    47. Re:So let me get this right... by KDR_11k · · Score: 1

      Will be out? I already grabbed W7 off MSDNAA a few days ago, what did I get there then?

      --
      Justice is the sheep getting arrested while an impartial judge declares the vote void.
    48. Re:So let me get this right... by Antity-H · · Score: 1

      You mean that on a major version number change they can't even partially break backward compatibility? I think they did too ... just not on this.

    49. Re:So let me get this right... by jonadab · · Score: 1

      > Under CP/M ... will not delete a file with lower case characters in its name.

      > I think MS-DOS is smart enough to fix this at the OS level.

      DOS just made all filename operations case-insensitive. That solved the lowercase-characters problem...

      But it *was* possible, in some DOS-based applications (e.g., certain well-known word processors; this was in the days before WYSIWYG) to create files with unfortunate characters in their filenames, which it was not possible to delete from the command prompt. (Space was the most common "unfortunate character" for this, because people who didn't understand the difference between an identifier and a description kept wanting to put spaces in their filenames, but there were other possibilities as well.)

      At least one major word processing company actually ended up adding a primitive file management interface, complete with the ability to delete, into their product.

      --
      Cut that out, or I will ship you to Norilsk in a box.
    50. Re:So let me get this right... by KlomDark · · Score: 1

      Yo, dummy, maybe you should RTFM and find HttpUtility.HtmlEncode() and HttpUtility.HtmlDecode() - these are part of the .NET framework to take care of the issue you are so upset about (These can be in your code-behind or in your Eval() statements in your databinding expressions. You must remember that not everyone needs to check their output, only their inputs. You were approaching the problem in a backwards fashion.

    51. Re:So let me get this right... by Alpha830RulZ · · Score: 1

      Are you kidding me? It's text! Microsoft considers plain text dangerous now?

      Oblig: Little Bobby Tables, we call him...

      Text -is- often dangerous.

      --
      I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
    52. Re:So let me get this right... by denis-The-menace · · Score: 1

      If the CapiCom.dll version 2.1.0.2 is what we are are talking about, you can get it in a Security Update for CAPICOM (KB931906) here:
      http://www.microsoft.com/downloads/details.aspx?FamilyId=CA930018-4A66-4DA6-A6C5-206DF13AF316&displaylang=en

      Publicly, MS says that CAPICOM will stay 32-bit and will NEVER release a 64-bit version and that no further versions will be released. They want you to use .NET's cryto stuff, instead.

      You can, however, get CapiCom.dll version 2.1.0.3 (November 8, 2008, 3:15:16 PM) from Office 2007 Service Pack 2. This is mentioned at http://support.microsoft.com/kb/970357.

      If someone know how to test for this bug but needs help to get this DLL out of the service pack file, I will gladly help.

      (Posting this will now kill my 7 mod points I moderated to this story alone, so I hope this is indeed what we are talking about.)

      --
      Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
    53. Re:So let me get this right... by DavidTC · · Score: 1

      He's not talking about when you pull from the DB.

      He's talking about data-bound controls, where a text field or something is linked to a field in the DB. (And hence he can't run it through any sort of conversion on the way in.)

      --
      If corporations are people, aren't stockholders guilty of slavery?
    54. Re:So let me get this right... by Tweenk · · Score: 1

      Same goes for folders and files with DOS device names like 'con', 'com2' or 'lpt1'.

      --
      Those who would give up liberty to obtain working drivers, deserve neither liberty nor working drivers.
    55. Re:So let me get this right... by shutdown+-p+now · · Score: 1

      You mean that on a major version number change they can't even partially break backward compatibility?

      They can, but not in such a major way. Breaking it so that 10% of all applications out there would require 1% of code be rewritten is not okay, but at least it's tolerable. Breaking it so that 100% of all applications would require 30% of code to be rewritten is definitely not acceptable.

    56. Re:So let me get this right... by cromar · · Score: 1

      I suggest using NHibernate, since you get to be fully OO and it generates parametrized SQL for safety. (You can use data binding with custom objects since .NET 2.0.) Then if you have a data object with a field containing HTML, you can deal with encoding at the object level...

      public virtual string thisIsPotentiallyDangerousUserText
      {
      get { return someHtmlString.Escape(); }
      set { someHtmlString = value.Escape(); }
      }

      That way you can be absolutely sure it is checked both going into and coming out of the database.

    57. Re:So let me get this right... by rodgster · · Score: 1

      Thanks for the info. I assume you could exact the capicom.dll as if you were going to slipstream SP2 into office 2007.

      Actually I was referring to KB967723.

      And interestingly enough, the patch for windows 2003 (64bit) installs on XP (64 bit) but it's download is not referenced from the KB. And apparently MS has said they won't provide a patch for XP (either 64 or 32).

      --
      Who will guard the guards?
    58. Re:So let me get this right... by KingMotley · · Score: 1

      Not really hard if that is what you want, just put the following code in the class your pages derive from, and problem solved for your entire project:

              Public Overloads Function Eval(ByVal expression As String, ByVal format As String) As String
                      Dim container As Object = Page.GetDataItem
                      Dim obj2 As Object = DataBinder.Eval(container, expression)
                      If ((obj2 Is Nothing) OrElse (obj2 Is DBNull.Value)) Then
                              Return String.Empty
                      End If
                      If String.IsNullOrEmpty(format) Then
                              Return Server.HtmlEncode(obj2.ToString)
                      End If
                      Return String.Format(format, obj2)
              End Function

              Public Overloads Function Eval(ByVal expression As String) As Object
                      Dim result As Object
                      result = MyBase.Eval(expression)
                      Return Server.HtmlEncode(result)
              End Function

      First, let me say I don't agree with this approach. You shouldn't be letting contaminated data into the database in the first place. That is your problem. Not encoding it on the way out is only a problem if you allowed the data to get into the database with embedded html in it. There are protection mechanisms in place that help prevent xss type code getting submitted, but I'm guessing you disabled it. The boundfield control also allows encoding HTML. It's been a while since I've used a form control, but I would typically use the literal control instead of a label. It's a lighter weight control, and as you see, it's more appropriate for outputting data in the manner you expect. Something like:

      <asp:Literal ID="lblNotes" runat="server" Mode="PassThrough" Text='<%# replace(system.Web.HttpUtility.HtmlEncode(Eval("Notes")),chr(13),"<br />") %>'></asp:Literal>

      Except here I've used the passthrough mode, encoded the string myself, so that I can convert CR's to an html BR.

      I've read your other posts, and what I see is the typical programmer who claims to know better, then turns around and complains when his code doesn't work well. Turning off security features, then complaining how insecure his app is, is your fault. It's the equivalent at saying how insecure a bank is, and blaming the vault manufacturer, cause the manager who knew better left the front door and the vault door open over night. Oh, and how insecure perl must be cause, slashdot didn't properly html encode my post by default.

    59. Re:So let me get this right... by KingMotley · · Score: 1

      Sorry, that should have been:

                      Public Overloads Function Eval(ByVal expression As String, ByVal format As String) As String
                                      Dim container As Object = Page.GetDataItem
                                      Dim obj2 As Object = DataBinder.Eval(container, expression)
                                      If ((obj2 Is Nothing) OrElse (obj2 Is DBNull.Value)) Then
                                                      Return String.Empty
                                      End If
                                      If String.IsNullOrEmpty(format) Then
                                                      Return Server.HtmlEncode(obj2.ToString)
                                      End If
                                      Return Server.HtmlEncode(String.Format(format, obj2))
                      End Function

                      Public Overloads Function Eval(ByVal expression As String) As Object
                                      Dim result As Object
                                      result = MyBase.Eval(expression)
                                      Return Server.HtmlEncode(result)
                      End Function

    60. Re:So let me get this right... by bill_mcgonigle · · Score: 1

      Speaking of which, I got to try that in server 2008, and Windows 7.. Its a fun way to use 3 lines of script to really piss off your IT co-workers...

      post your 3-line script. People here are calling BS.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    61. Re:So let me get this right... by snowgirl · · Score: 1

      The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.

      Don't worry, I'm sure this bug is on their SCRUM backlog...

      --
      WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
    62. Re:So let me get this right... by TheThiefMaster · · Score: 1

      I thought this one was interesting: http://www.dynamicarcade.co.uk/Dumping%20Ground/wtf%20filename.png
      Strangely the file disappeared when I refreshed the window after renaming it.

    63. Re:So let me get this right... by UnixUnix · · Score: 1

      >The SysInternals guys wrote a nice article about it once, I think, but I can't find it any more. http://technet.microsoft.com/en-us/sysinternals/bb897446.aspx "Hidden Registry Keys". I enjoyed running Reghide back then.

    64. Re:So let me get this right... by vrmlguy · · Score: 1

      (*) at least it SHOULD be rare, because it totally breaks the separation between UI, Code and Data, by mixing all three together into one huge mess.

      But it's a tasty mess!

      --
      Nothing for 6-digit uids?
    65. Re:So let me get this right... by Heembo · · Score: 1

      *applause* It's even worse - the new ASP output encoding API's only encode for HTML Entity - what about JS, CSS, HTML Attribute and other encoding contexts that you need for secure programming to stop XSS? Not to mention DOM based XSS where you need to encode for JS Variable AND HTML Attribute, in some cases. Web Security Programming is not easy - and its frankly impossible if you don't have the right tools.

      --
      Horns are really just a broken halo.
    66. Re:So let me get this right... by Heembo · · Score: 1

      Correct, if you store HTML in your database, you need to VALIDATE your data using a HTML Policy tool like OWASP AntiSamy. But really, you should never store ENTITY encoded data in the database, you should encode at your use boundary in your UI layer.

      --
      Horns are really just a broken halo.
    67. Re:So let me get this right... by Anonymous Coward · · Score: 0

      Just tried this and it "works" in server 2008 R2 too.

    68. Re:So let me get this right... by Anonymous Coward · · Score: 0

      "del /s *.*" is not able to delete such folders
      but a
      "rmdir /s ." succeeds to delete them.

    69. Re:So let me get this right... by Jaime2 · · Score: 1

      BTW, to make a div or span into a control, just add runat="server" and id attributes to them. They work just fine that way and fully encode HTML all by themselves.

      As for data binding -- use textboxes for input, they refuse to accept tags. Then you don't have the problem of encoding the data on the way out. As for the label, although it doesn't HTML encode, I can't think of too many cases where I would display user submitted data in a label. It seems like a rare issue to me.

      I also don't like to use declarative binding in my ASP/Net apps. For me the .aspx file has only presentation, no binding logic. The code behind page has UI logic including binding. All other code goes into the business or data layer class libraries.

  5. Wow? by Anonymous Coward · · Score: 4, Funny

    Moxie Marlinspike - that's a goblin name if I ever saw one.

    1. Re:Wow? by captnbmoore · · Score: 4, Informative

      You do know what a marlinspike is right? http://en.wikipedia.org/wiki/Marlinspike

      --
      The Navy Motto "IF it ain't broke Fix It" "A day is wasted if you don't learn something new"
    2. Re:Wow? by The+Archon+V2.0 · · Score: 2, Insightful

      You do know what a marlinspike is right?

      Yeah, it's the place where Captain Haddock lives. (I'm sorry, I know what the actual object is, but my childhood Tintin reading and viewing has forever fused the word "marlinspike" to the word "hall".)

    3. Re:Wow? by PhunkySchtuff · · Score: 1

      I know what a Marlinspike is, but wft is a Moxie?

    4. Re:Wow? by captnbmoore · · Score: 1
      Here you go.

      http://en.wikipedia.org/wiki/Moxie

      Looks like a carbonated rope twister.

      --
      The Navy Motto "IF it ain't broke Fix It" "A day is wasted if you don't learn something new"
    5. Re:Wow? by Hyppy · · Score: 1

      I know what a Marlinspike is, but wft is a Moxie?

      I don't know, but Knob Goblins fear it.

  6. Is that... by petronije · · Score: 2, Interesting

    a bug or a feature?

  7. What about the CA that issued it? by mindstrm · · Score: 5, Interesting

    With CNs like www.paypal.com\0ssl.secureconnection.cc

    Shouldn't the CA who issued the certificate bear *some* of the blame here?

    It just seems logical....

    1. Re:What about the CA that issued it? by Anonymous Coward · · Score: 0

      Yes, the ideal solution is to revoke the entire upstream chain and re-issue new certificates to anyone affected.

    2. Re:What about the CA that issued it? by Anonymous Coward · · Score: 1, Funny

      But regular expressions are hard!

    3. Re:What about the CA that issued it? by ekhben · · Score: 5, Insightful

      Ahh, you've discovered why SSL on the web is fundamentally broken -- CAs have no incentive to act responsibly, since their customers are certificate requestors, not relying parties. And certificate requestors like CAs who don't have heavy process and high fees.

      I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.

    4. Re:What about the CA that issued it? by QuoteMstr · · Score: 5, Interesting

      CAs have no incentive to act responsibly, since their customers are certificate requestors, not relying parties. And certificate requestors like CAs who don't have heavy process and high fees.

      Especially Comodo:

      Five minutes later I was in the possession of a legitimate certificate issued to mozilla.com - no questions asked - no verification checks done - no control validation - no subscriber agreement presented, nothing

    5. Re:What about the CA that issued it? by Timothy+Brownawell · · Score: 1

      I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.

      Something else that should work (once DNSSEC is actually implemented everywhere) would be to list your SSL fingerprint as a DNS entry. This is less secure in some ways (say, if someone hijacks your account with whoever you bought your domain from), but better in others (better assurance on first visit, you can change the fingerprint if your server is compromised and someone else gets hold of your cert's private key).

    6. Re:What about the CA that issued it? by Culture20 · · Score: 1

      With CNs like www.paypal.com\0ssl.secureconnection.cc

      Shouldn't the CA who issued the certificate bear *some* of the blame here?

      So I can't have a .paypal.com\0ssl.secureconnection.cc subdomain of secureconnection.cc?

    7. Re:What about the CA that issued it? by misnohmer · · Score: 1

      Not exactly. I'm not one to defend the CA's, there is no shortage of irresponsible behavior examples from them (say, the MD5 collision attack, why continue using MD5 signatures years after the theoretical exploit was published), HOWEVER, in this case the CA's have it properly implemented, as per specification. Specification says PASCAL type strings, and that's how they should be handled. The problem is the implementation of the CN string handling as a C/C++ null-terminated string by the crypto functions or the application (like the browser) itself. CA's shouldn't be blamed for someone else having bad code.

    8. Re:What about the CA that issued it? by jpmorgan · · Score: 1

      What about the CA that issued a cert for *.secureconnection.cc? Do those ones bear any blame?

    9. Re:What about the CA that issued it? by buchner.johannes · · Score: 3, Interesting

      Jacob Appelbaum presented a wildcard cert that you can use for any domain a week ago. Not sure why this is a story when a paypal-only forged cert comes out.

      https://www.noisebridge.net/pipermail/noisebridge-discuss/2009-September/008400.html

      Note that you can create a SSL cert for any subdomain you host. I.e. CA root gives you *.example.com, you sub-certify a certificate for mail.myhome.example.com. So you can not blame a root CA for this issue, as anyone who is in the hierarchie can create a \x00 cert.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    10. Re:What about the CA that issued it? by onefriedrice · · Score: 1

      Which is why I sometimes get a little irritated when I'm trying to explain to people who just won't understand that CA-issued certificates are hardly more secure than self-signed certificates. In reality, CA-signed certificates are more dangerous because of the false sense of security people get when they see the friendly "lock" icon without even having to look at the certificate. Yet, some common browsers today make people jump through all sorts of hoops just to accept a self-signed certificate.

      --
      This author takes full ownership and responsibility for the unpopular opinions outlined above.
    11. Re:What about the CA that issued it? by gzipped_tar · · Score: 1

      See IETF RFC 952 and RFC 1123.

      --
      Colorless green Cthulhu waits dreaming furiously.
    12. Re:What about the CA that issued it? by ekhben · · Score: 1

      You mean, something like RFC 4255, the SSH key RRTYPE? Such a beast has been proposed in the IETF dnsext WG, current status seems to be withdrawn pending further work, as of July this year, but I haven't seen it re-submitted. The agenda for IETF 76 in early November isn't set yet, but alas, both pkix and v6ops conflict with dnsext, so I am likely to miss that session.

      (Might be worth trawling the mail archive for dnsext on this subject here).

    13. Re:What about the CA that issued it? by Anonymous Coward · · Score: 0

      A universal wildcard certificate has been distributed with sslsniff since its 0.6 release. This paypal certificate is news because unlike the wildcard cert, it affects the MS crypto API, which hasn't been patched.

    14. Re:What about the CA that issued it? by mpe · · Score: 2, Informative

      Which is why I sometimes get a little irritated when I'm trying to explain to people who just won't understand that CA-issued certificates are hardly more secure than self-signed certificates. In reality, CA-signed certificates are more dangerous because of the false sense of security people get when they see the friendly "lock" icon without even having to look at the certificate.

      You also typically will not get any warning if the certificate or the CA change.

      Yet, some common browsers today make people jump through all sorts of hoops just to accept a self-signed certificate.

      Together with "warnings" which are misleading.

    15. Re:What about the CA that issued it? by mpe · · Score: 1

      I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.

      Part of the reason that it's broken is too many global "roots" and a lack of hierarchy.

    16. Re:What about the CA that issued it? by maxwell+demon · · Score: 1

      And the specification says nothing about the characters allowed to be contained in those PASCAL type strings? Or it says that NUL is one of the allowed characters?

      --
      The Tao of math: The numbers you can count are not the real numbers.
    17. Re:What about the CA that issued it? by misnohmer · · Score: 1

      From the exploit write-ups, evidently NUL is a valid character in a PASCAL string. Nothing wrong with that since it contains the string (or array) length at byte offset 0. Notice that NUL is also a valid value for any member of a char array in C/C++, it's just that C didn't have a explicit data type called string, so instead it uses a NUL terminated char array as strings.

      This is simply a data type compatibility issue, no different than a problem where integers are 32 or 64 bit between platforms. Whoever implemented the C/C++ extraction of the CN, should have considered that - bad implementation and bad test coverage.

    18. Re:What about the CA that issued it? by Luyseyal · · Score: 1

      I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.

      How about making your URL bar turn green if you have a cert from a real CA? The browser vendors could get together and say "look if you want the green bar treatment, you have to go through this official CA process with real vetting." That way, null certs from crappy CAs won't get green-barred, even if the URL itself is correct.

      Random thought,
      -l

      --
      Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
    19. Re:What about the CA that issued it? by Anonymous Coward · · Score: 0

      I read your link (I know, uncharacteristic for a slashdot user), and as noted in it, that certificate is only good for libnss bugs, and not the Win32 API. The libnss bugs have been patched. This certificate is good for an attack vector that isn't patched, probably won't be patched for a long while, and affects a very large percentage of the internet population. It is also good for a site that does financial transactions. This is really nasty.

    20. Re:What about the CA that issued it? by DavidTC · · Score: 1

      And banks and whatnot should offer to email people who sign up for net access some sort of installable cert, or a program that checks if their saved cert is correct.

      Seriously, SSL was stupid to start with. The SSL trust model is especially stupid.

      --
      If corporations are people, aren't stockholders guilty of slavery?
    21. Re:What about the CA that issued it? by maxwell+demon · · Score: 1

      Yes, NUL is a valid character in a Pascal string. But the question is: Is it also a valid character in the Field. For example: 35 is clearly a valid integer. Yet, it should clearly not be accepted in the day-of-month field of a date, despite the fact that the day-of-month field contains an integer, which 35 is. I strongly doubt that being a Pascal string is the only requirement for the field (otherwise it would be pretty worthless for authentication).

      --
      The Tao of math: The numbers you can count are not the real numbers.
    22. Re:What about the CA that issued it? by Anonymous Coward · · Score: 0

      The certificate is valid for * on the internet (when exploiting libnss software). The certificate is good for two years. It won't work for exploiting the bug for software written with the WIN32 api, they don't accept (for good reason) *!

    23. Re:What about the CA that issued it? by ekhben · · Score: 1

      I'd disagree with "SSL was stupid to start with." SSL is just fine. x509 is, likewise, just fine. Both are technologies that are well suited to their particular roles.

      The use of x509 as a trust model for HTTPS, that was stupid to start with. x509 solves the problem of hierarchical trust. The web is not hierarchical. Fail.

    24. Re:What about the CA that issued it? by ekhben · · Score: 1

      Yes. It doesn't help because few users and server admins understand the difference, and for those that do, it's too dilute a message. It further doesn't help because even if you configured your browser to reject any non-EV certs you've just hit a magic reset button, and you haven't solved the fundamental problem that CAs are not accountable for what they sign. (Imagine if you remove an operator's EV status, how long will it take to propagate that change to all browsers?)

    25. Re:What about the CA that issued it? by misnohmer · · Score: 1

      The X.509 certificates are used for many purposes, not just ssl. A Common Name (CN) field is a generic field defined under the spec. Since there is no spec defining what a valid set of chars are in the CN for SSL, I don't think we want CA's to be going off deciding whatever they feel is valid based on what breaks someone else's implementation. What if they decide that com.com breaks some poor implementations, hence they'll never issue a certificate for cnet (who owns com.com) or even supercom.com or malcom.com. It really should the the responsibility of the implementers who use X.509 certificates to deal with all possible values allowed by the X.509 spec - even if the "dealing with it" means throw an error saying "unable to process this certificate".

  8. Such dependancies annoy nLite users! by BikeHelmet · · Score: 0

    This includes IE, Chrome, and Safari on Windows. What's worse, because of the OCSP attack [CC] that Moxie also presented at Defcon, this certificate cannot be revoked."

    It irks me how much Microsoft and Google products depend on Windows components.

    I'm an avid nLiter for my own personal computers. Google uses BITS for updates, and apparently MS Crypto too. This is all stuff that I strip out entirely, because just about all non-Microsoft non-Google software works fine without it.

    If there's one thing I've learned about software development, it's that if you depend on system APIs, you're more likely to get attacked. After all, every Windows computer has such libraries, so why wouldn't hackers target it? Short of heavily modified/nLited XP computers, you'd have a 100% attack base if you can find an exploit in the component, or a way to exploit that component's behaviour.

    As a developer, if you have an option about what you use to handle something... like crypto or updates... code it yourself and code it properly, or go for a third party library. (perhaps open source) XML Parsing? Code it yourself or use a third party lib, but DO NOT use MS XML parsing. You're asking for trouble if you do!

    1. Re:Such dependancies annoy nLite users! by Anonymous Coward · · Score: 5, Insightful

      This has to be the worst advice I've ever heard.

    2. Re:Such dependancies annoy nLite users! by Shikaku · · Score: 1

      Install less software to protect yourself?

      Yeah, that's like wearing little armor to be able to dodge all enemy attacks. You have to know what the hell you are doing, and even then it can still be disasterous.

    3. Re:Such dependancies annoy nLite users! by sakdoctor · · Score: 4, Insightful

      NO! Don't roll your own crypto. This is madness!
      *Kicks BikeHelmet into pit*

      OpenSSL is available for windows; use that.

    4. Re:Such dependancies annoy nLite users! by Anonymous Coward · · Score: 0

      or go for a third party library.

      Like the crypto and update functionality built in to the OS?

    5. Re:Such dependancies annoy nLite users! by TheRealMindChild · · Score: 2, Insightful

      It irks me how much Microsoft and Google products depend on Windows components.

      So you are saying reinvent the wheel? Don't use the system resources at your disposal? Should we just all go back to DOS way of doing things?

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
    6. Re:Such dependancies annoy nLite users! by just+fiddling+around · · Score: 3, Insightful

      Amen brother, bad coders re-making existing functions or API's is what fills up The daily WTF

      --
      You're not old until regret takes the place of your dreams.
    7. Re:Such dependancies annoy nLite users! by Anonymous Coward · · Score: 0

      What software do you develop? I want to make damn sure I never use it.

    8. Re:Such dependancies annoy nLite users! by True+Vox · · Score: 2, Insightful

      Yeah, I'll just echo Sakdoctor... Being able to make "rolling your own crypto" a good idea is for a VERY rare breed of person... and even they generally don't like to do it.

      --
      "Gratuitous complexity is akin to chaos" - True Vox
    9. Re:Such dependancies annoy nLite users! by Anonymous Coward · · Score: 0

      You are advocating security through obscurity. That may be a good thing here, or may not be. But it's worth pointing out either way.

    10. Re:Such dependancies annoy nLite users! by Fulcrum+of+Evil · · Score: 1

      Install less software to protect yourself?

      Yeah, that's like wearing little armor to be able to dodge all enemy attacks. You have to know what the hell you are doing, and even then it can still be disasterous.

      It's more like parking fewer cars on the street in north jersey - every app is a way to be attacked.

      --
      "We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
    11. Re:Such dependancies annoy nLite users! by Anonymous Coward · · Score: 0

      So you are saying reinvent the wheel? Don't use the system resources at your disposal? Should we just all go back to DOS way of doing things?

      No, use OpenSSL and other cross-platform libraries. Rather than having each *OS* reinvent the wheel.

    12. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      Install less software to protect yourself?

      Use different software. There's a difference between not using anything, and preferring manually installed FOSS to Microsoft's solution.

    13. Re:Such dependancies annoy nLite users! by QuoteMstr · · Score: 1

      No, use OpenSSL and other cross-platform libraries. Rather than having each *OS* reinvent the wheel.

      So in your book, a monoculture is okay so long as it's an open source monoculture?

      OpenSSL's license is incompatible with the GPL, by the way, so we need at least two SSL libraries in the world.

    14. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 2, Interesting

      NO! Don't roll your own crypto. This is madness!

      I'd never do that.

      OpenSSL is available for windows; use that.

      ->

      go for a third party library. (perhaps open source)

      The rewrite it bit was actually referring to automatic updates and XML parsing. Those are pretty easy to implement properly in an app, without depending on Microsoft-coded services.

      Apparently I'm 80% overrated, but that's also why a single exploit can affect so much software. Rather than using a third party lib, most devs just use whatever you stick in front of them. :/

    15. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      Hehe... it'd be a horrible idea for me. :D

      But automatic updates and XML parsing are easy. I wouldn't expose an app to the vulnerabilities Microsoft's implementations provide.

    16. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      No. Just consider where you're placing your faith.

      As someone above posted - OpenSSL or MS Crypto? I know which one I'll be using!

      Java XML Parser? MS XML Parser? Have you seen the number of published exploits and fixes released?

      Automatic updates for your app?

      Those last two are probably best implemented by reinventing the wheel.

    17. Re:Such dependancies annoy nLite users! by QuoteMstr · · Score: 1

      Java XML Parser? MS XML Parser? Have you seen the number of published exploits and fixes released?

      What makes you think your own code is any better?

    18. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      I read that site sometimes. I don't make mistakes like that - not because I'm brilliant, but because I actually write unit tests and try to fark my own code over. I never assume because I think it should work, that it will work.

      For me, actually writing code is probably less than 20% of the time spent on a piece.

      I also follow the rulebook when it comes to sanitizing input, or anything that could be modified by a user.

      But none of this has anything to do with not depending on Microsoft when third party libs are available.

    19. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      You are advocating security through obscurity.

      Somewhat - but I prefer security through limited feature sets.

      In the case of XML Parsers, they have a lot of features, and XML can have very complex syntax. New exploits pop up quite often. If you only need to store a few settings, why not roll your own simplistic XML parser? Or go even simpler and use INI!

      For an XML parser, make it only understand <tags>, data inbetween tags, and spit out errors if there isn't an ending tag for every single tag, in exactly the right order. Sanitize all input with checks for <> or other special chars.

      Make it ASCII only too, since it's only storing settings - perhaps even limit it to opt-out sanitization rather than opt-in, and just accept characters or numbers.

      How do you crack that? You can't. Some strange exploit related to unicode characters isn't going to break open an exploit 2 years from today - if you did proper unit testing, and your code is bug free, then you just wrote an "unhackable" XML parser, which at the worst will just reject files as not having valid syntax.

      I call that "rock solid", and for high-risk code, I'll always go for a reduced feature set and more security.

      Note: I would never roll my own crypto. I do place great faith in OpenSSL...

    20. Re:Such dependancies annoy nLite users! by Hyppy · · Score: 1

      Java XML Parser? MS XML Parser? Have you seen the number of published exploits and fixes released?

      What makes you think your own code is any better?

      His own code can be easily updated when it needs to be. Microsoft's... heh heh.

    21. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      Java XML Parser? MS XML Parser? Have you seen the number of published exploits and fixes released?

      What makes you think your own code is any better?

      His own code can be easily updated when it needs to be. Microsoft's... heh heh.

      There's truth in that, but I also limit the implemented features.

      If you stick with simplistic syntax, it's much easier to cut down on attackable surface. When I wrote an XML parser for app settings, I chose...

      ASCII only, no XML attributes(only simple tags), strict closing tag order. Also, opt-out input sanitization(all chars rejected unless... A-Z, a-z, 0-9, +_-, etc.) when both saving and loading.

      I'm not a genius; limiting features and scope can be done by any half-decent coder that spends some time designing before coding. Just figure out what you actually need to complete your task(in my case, storing program settings), and figure out if there's a third party lib which works, or whether you should roll your own. If rolling your own, design before you begin to code.

      All the exploits hitting MS's XML Parsers and even the Java XML Parser really encouraged me to build my own. It's not a proper implementation of any XML spec, but anyone can look at it and edit it in notepad, and the worst that can happen is the file gets rejected as containing invalid syntax. Or, if they try to add attributes, it complains about a missing closing tag. Either way, no exploit. :P

      I think the whole thing was under 200 lines of java code, too. Certainly not mind-boggling.

    22. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      The rewrite it bit was actually referring to automatic updates and XML parsing. Those are pretty easy to implement properly in an app, without depending on Microsoft-coded services.

      No necessarily. I work with lots of companies on various international standards. I've seen companies try to roll their own XML parser in their products. 9 times out of 10, they fack it up. Not necessarily from a exploitation point of view, but from a compliance point of view. I've seen home-grown xml parsers that failed to or improperly parsed comments, empty elements, white spaces,or most commonly, failed to properly handle namespaces.

      Now I'm not saying it can't be done properly, as I've done it before. I'm just saying that in general it's bad advice to tell someone to roll something themselves when there exists a core library that they can take advantage of, because not everybody is as competent as you. Believe me, I've seen all sorts of crazy logic in people's XML parsing logic, when I was helping companies with interop testing of their products.

    23. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1
      The only problem with your approach, is that it's very inflexible. Just figure out what you actually need to complete your task . I can understand that approach, but at the last company I worked at, it was the undoing of the company. All the modules they outsourced to be implemented were all designed to solve the EXACT task at hand, and could not easily be extended or reused for other tasks. When new functionality had to be designed to work with existing functionality, it was pretty much determined that the entire system needed to be re-written, which caused the company to almost go through bankruptcy to try to fix their designs...

      On the same token, I can see your point about not wanted to use existing libraries, as at this same company, when I first started, I wrote my own modules that duplicated some functionality of that company's core libraries, but I did it for architectural reasons. I trimmed a month-end process from taking 6 hours to run to under 10 minutes, because I saw the way they were storing and passing data was designed by a moron. I was reprimanded by said company for "re-inventing" the wheel. I now work for a company that advocates re-use when applicable, but re-design when necessary. :) However, I would never generalize and recommend people to always roll their own stuff, because at current company, I have a coworker that did just that, and facked up our whole project, with his idiotic assumptions and program logic.

      If rolling your own, design before you begin to code.

      Dude, you should be doing that with ALL your code, regardless if you are re-inventing something or not...

    24. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      and the worst that can happen is the file gets rejected as containing invalid syntax

      What if your parser accepted a CDATA element because it passed sanitization, but then because you didn't properly embed CDATA support misparsed an embedded close tag as a real close tag, than passed corrupt data as real data. Voila, that's how you encounter an unintended buffer over-run exploit....

    25. Re:Such dependancies annoy nLite users! by poopdeville · · Score: 1

      I used to read that site, until they started deleting my comments. Then they randomly snail-mailed me an advertisement from Microsoft. (wtf?)

      Data normalization is always a good thing, for a programmer. And it exposes the possibility of purely monadic programming. (Essentially, this amounts to programming on generic containers for a type.) But they DUR DON'T GET IT. They would rather be using crap like the 'factory pattern' and its friends (which is basically an abuse of an object system, hence hard to figure out wtf is important about the programming construct when seeing it "live" -- a portion of code can implement or be a part of many patterns simultaneously) instead of writing a functor (essentially a function from a set of functions to a set of functions.)

      Fuck their lame little clique. They're worse than Python developers. I had been reading since 2004, too.

      --
      After all, I am strangely colored.
    26. Re:Such dependancies annoy nLite users! by poopdeville · · Score: 1

      XML's syntax is isomorphic to Scheme's. Throw in a lambda tag and you have a functional programming language. Once a developer is capable of realizing that much, they can form a picture of how hard writing an XML parser will be. (Easy) I could probably make a simple, fully-compliant, slow parser in a day or two, with a functional programming language like Haskell or Scheme (though I'm out of practice in Scheme). It would take me longer to do it in a procedural or object oriented language. It's hard to say how long, and it would depend on the language. Perl, for example, is rich enough to simulate many functional programming constructs directly. Java... not so much. Which basically means I'd have to write a parser, in Scheme say, and write a parser renderer in that same language to generate a state transition table suitable for Java. Or use Yacc (yet another functional programming language... I mean, "yet another compiler compiler") or the Java equivalent. Jacc?

      Any other approach for Java or C and the like is madness. I suppose you can do some neat things with function pointers, but they aren't even closures, let alone first class functions. That means you will have to carry "irrelevant details" around when defining your grammar in terms of function pointers. All that noise does is obscure the fact that you're defining a grammar. A state transition table will potentially make a giant blob of ugly code, but at least all the ugliness is contained in a single table (leaving a clean interface and plenty of room for your business logic elsewhere) and at least all the ugliness is machine generated, from an easily understood grammar.

      Programming is really easy when you know some graduate level mathematics and mathematical logic... heh.

      --
      After all, I am strangely colored.
    27. Re:Such dependancies annoy nLite users! by Anonymous Coward · · Score: 0

      but DO NOT use MS XML parsing.

      Even better: DO NOT USE THAT MICROSHIT CLUSTERFUCK!

    28. Re:Such dependancies annoy nLite users! by mugnyte · · Score: 1

        Depending on system API's, external libraries, etc is how one gets a LOT done on a modern programming platform. You want to fix time to some point and code everything after that, be my guest. But you cannot keep up with the world, and yes sometimes you'll use exploitable or buddy code (most likely your own). It comes with the territory of programmable machines (in hw or sw).

        I'm all for keeping software towards the "free" side or other philosophical goals, but replacing components is just dumb. Using them appropriately once you understand them, and their quirks has been the mark of a guru for a long time. IF they don't function for your purpose, look elsewhere, but for chrissakes don't ignore the efforts off the world around you.

    29. Re:Such dependancies annoy nLite users! by Bert64 · · Score: 1

      Less armor makes you lighter and more agile, and thus better able to dodge attacks or run away?

      Not that this is a valid analogy, every piece of code running on your system could potentially have security flaws... More code, more chance of exploitation.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    30. Re:Such dependancies annoy nLite users! by shutdown+-p+now · · Score: 2, Insightful

      XML parsing. Those are pretty easy to implement properly in an app

      No, no, God, no. I'm sick to death of crappy applications not handling Unicode element names, not understanding XML namespaces properly (I've seen several that thought that prefix is the namespace, and required you to use specific prefixes), not properly parsing CDATA, not understanding XML whitespace rules or xml:space, not understanding DOCTYPE and entities, and so on.

      XML is not simple. Don't think you can whip up a parser in an evening unless you really know the W3C spec well, including all corner cases (if you don't know any corner cases, then you don't know it well).

      Use a mature, stable, preferably open source third party library, and you'll make your users and future maintainers happy.

    31. Re:Such dependancies annoy nLite users! by shutdown+-p+now · · Score: 2, Informative

      When I wrote an XML parser for app settings, I chose...

      ASCII only, no XML attributes(only simple tags), strict closing tag order. Also, opt-out input sanitization(all chars rejected unless... A-Z, a-z, 0-9, +_-, etc.) when both saving and loading.

      So you didn't write an XML parser, then. I sure hope that when you documented that thing, you didn't call the format of your app settings file "XML", because it sure as hell isn't that.

    32. Re:Such dependancies annoy nLite users! by rdebath · · Score: 1

      More like carrying fewer weapons, so leave the hydrofluoric acid and nerve toxin behind. Then think seriously if you really need the molotov cocktails.

      Even a thirty pound sledge might be a good weapon, but if you have to drop it before you can move all you've accomplished is to make it available to the other guy.

    33. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      So you didn't write an XML parser, then. I sure hope that when you documented that thing, you didn't call the format of your app settings file "XML", because it sure as hell isn't that.

      It parses and generates valid XML files, readable or writable by other parsers - as long as you stay away from attributes. ;)

      But I understand your point. Technically it's not an XML parser.

    34. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      The settings file is settings.xml, and can be read by other xml parsers.

      Typical output from saving settings would be something like this:

      http://www.w3schools.com/XML/plant_catalog.xml

      (Although for a settings file, there's no need to have characters like $; for storing text, there would be)

      You'll notice the ASCII text and lack of attributes on anything - but it still gets the job done and people call it XML. You can insist I didn't create an xml parser, and I will agree with you - I created a ProgramSettings parser, and it generates 100% valid (but very simple) XML.

      Again, the purpose was not to parse all XML files, or greatly increase the attack surface by having tons of complicated syntax. The purpose was to store and retrieve program settings to/from an easy to edit format.

      I guess I just got tired of ini. Spent too long configuring Samba on Ubuntu. ;)

    35. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      Input sanitization would catch the uneven number of closing tags, assuming you somehow confused it.

      As stated, sanitization is done when both loading and saving. In this case it would just reject it as an invalid file.

      And before you ask, it also sanitizes identical element names directly inside each other.

      But since the input sanitizing code filters all that out, it's a non-issue unless you're manually editing in notepad. And if I've done my job properly, you'll have a GUI to change all settings, so you'll never have to hunt around in a settings file... :/

    36. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      However, I would never generalize and recommend people to always roll their own stuff

      I recommended investigating third party libs and considering rolling your own, rather than using Microsoft's solution. I'm going to have to stand by my statement on this one.

      You are right that always rolling your own is a very bad thing.

      Dude, you should be doing that with ALL your code, regardless if you are re-inventing something or not...

      Some people like to start coding before designing. I've met people that had to hammer on a keyboard to get their thought processes going - usually the code gets 100% rewritten as soon as the design is complete and accepted.

      I personally don't have that, but I can't find a valid reason for arguing against it.

    37. Re:Such dependancies annoy nLite users! by jonadab · · Score: 1

      > Once a developer is capable of realizing that much, they can
      > form a picture of how hard writing an XML parser will be. (Easy)

      That's the main point of well-formedness. XML is *designed* to be easy to parse.

      > I could probably make a simple, fully-compliant, slow parser in a
      > day or two, with a functional programming language like Haskell...

      A *day* or two?

      I could write an XML parser in Perl in an hour, if I didn't mind re-inventing something that already exists on the CPAN.

      --
      Cut that out, or I will ship you to Norilsk in a box.
    38. Re:Such dependancies annoy nLite users! by shutdown+-p+now · · Score: 1

      It parses and generates valid XML files, readable or writable by other parsers - as long as you stay away from attributes.

      Not parsing attributes is actually fine if your schema disallows them anyway (though there are also namespace declarations...). But what about e.g. entities defined in a DOCTYPE? If the input is valid XML, I expect to be able to use entities to refactor repeated parts of that input.

      I don't really have a problem with using your own format, just please don't misidentify it as XML. It results in trouble down the line when someone reads that you use XML, believes it, and uses a conformant XML writer (or XSLT engine, or whatever) to produce it, and it turns out that the output has something that your "XML" parser cannot handle, but really should - like, say, spurious namespace declarations. If you clearly say that it's not XML, and provide its grammar (or specify which subset of XML is allowed by identifying the features that are not), then it's not an issue at all.

    39. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      And before you ask, it also sanitizes identical element names directly inside each other.

      But it's perfectly legit to have embedded elements with the same name.

      What you describe is fine if you have full control over the inputs, but in the real world, you'll find that other people as well as other groups could be interfacing with your API. In such a case, another person might see that your module takes XML as input, and code their module to output XML that is valid and spec compliant, but your module chokes on.

      What if, for example, another group needs to use your modules, but they need to pass UTF-8 encoded strings, because they are using the module in China/Korea/etc? You wrote your module to only accept ASCII. Or what if they need to pass a Base64 or BinHex encoded byte array as part of their persisted state? What if they added prefixes to all your elements, and then defined that namespace to be the default namespace in your normal XML you expected. Your sanitization prohibits the colon character, so you are basically saying you don't allow any namespace definitions. That is very inflexible, because not only are you preventing the use of namespaces, you are preventing the declarations for schemas as well. Things that are actually HELPFUL with document validation.

      So like I was saying. For a small operation where you control the inputs/outputs, that is fine, but even then, people may try to reuse your module later, and have to re-write it to get it to work. Then you'll have even more points of failure. In most real world scenarios, you have to think outside the box, and design some level of extensibility into your modules. Or do you think OS writers should also change their design paradigm and force you to re-compile the entire OS whenever you want to enable/disable features?

    40. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      What if the CDATA element did not cause you to prematurely close a tag, but instead had valid XML elements, that duplicated the names of siblings (since you said your sanitization only checks for nested duplication), this can cause you to incorrectly overwrite data into your variables.

      Or what if the CDATA element had null characters in it, causing the entire XML document to get truncated in your string handling. Suppose the CDATA element also had just the right amount of XML in it, that it would all still pass your sanitization, as it had all valid characters and elements, and the right number of close tags... Only problem, is if the CDATA element was the first element, the CDATA element can essentially pass fake information into your code, and have incorrect data get persisted/loaded.

      Might not sound like much, but if you are working with financial information, for example, this is a HUUUUGE breach.

    41. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      I could write an XML parser in Perl in an hour, if I didn't mind re-inventing something that already exists on the CPAN.

      You can implement the entire W3C XML spec, in an hour, and have no mistakes in your logic? BULLSHIT. I've seen companies fack up an XML implementation that they spent weeks/months working on. I have real world experience, as I worked with these said companies doing interop testing of their products. Almost all of them screwed up basic XML parsing.

    42. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      That's the main point of well-formedness. XML is *designed* to be easy to parse.

      XML was designed to by easily HUMAN READABLE, not to be easily parsed. For example, a binary encoded data blob is much easier to parse than XML. Parsing XML tokens is easy. Assembling the tokens into their proper form not so much, especially when you have to deal with custom schema defined data types and such.

      Working on international standards, I find many companies have a hard time just agreeing on the correct interpretation of a particular spec. All it takes is two implementations to interpret the spec differently, and you can have two incompatible solutions.

      Like I said, I know it can be done (I actually wrote an XML parser to be used on an embedded platform, that was tested/certified for compliance), I'm just saying it is NOT a trivial task, and cannot be done correctly in only an hour's time....

    43. Re:Such dependancies annoy nLite users! by Disgruntled+Goats · · Score: 1

      So you're advice against being attacked through monoculture is for everyone to move to another monoculture? Why wouldn't these people then not just go and target that third-party library that everyone is now using instead of the Win32 API?

    44. Re:Such dependancies annoy nLite users! by greengearbox · · Score: 1

      > Once a developer is capable of realizing that much, they can > form a picture of how hard writing an XML parser will be. (Easy) That's the main point of well-formedness. XML is *designed* to be easy to parse. > I could probably make a simple, fully-compliant, slow parser in a > day or two, with a functional programming language like Haskell... A *day* or two? I could write an XML parser in Perl in an hour, if I didn't mind re-inventing something that already exists on the CPAN.

      You people don't know what the fuck you're talking about. XML parsing is not easy. What is easy is writing a parser for a half-assed subset of whatever parts of XML you feel like you need.

    45. Re:Such dependancies annoy nLite users! by poopdeville · · Score: 1

      A fully compliant XML parser is only a few hundred lines of Haskell code. A fast XML parser is a little longer.

      See http://hackage.haskell.org/packages/archive/HaXml/1.19.7/doc/html/src/Text-XML-HaXml-XmlContent-Parser.html for an XML parser implementation.

      --
      After all, I am strangely colored.
    46. Re:Such dependancies annoy nLite users! by poopdeville · · Score: 1

      Would you like to see a fully compliant XML parser, written in a few hundred lines?

      http://hackage.haskell.org/packages/archive/HaXml/1.19.7/doc/html/src/Text-XML-HaXml-XmlContent-Parser.html

      Writing an XML parser in a few hours is impossibly difficult. Writing it in a few days is not. It's no harder than writing an S-expression parser. This is a task freshmen students are given in Introductory Scheme courses. (Typically, they get a few weeks to write parsers and evaluators, in order to implement a Scheme runtime, written in Scheme.)

      --
      After all, I am strangely colored.
    47. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      Might not sound like much, but if you are working with financial information, for example, this is a HUUUUGE breach.

      Good thing it's storing settings - like which side of the screen a toolbar is attached to, and what buttons are visible. ;)

    48. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      Your point? Look at the change log for haxml. There were many bug fixes along the way in each version. The whole project took more than "an hour" to get right. THAT was my point. You can't just sit down and roll your own XML parser thinking it's any easy one hour task to get right...

    49. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      In most real world scenarios, you have to think outside the box, and design some level of extensibility into your modules.

      If you have to do any of what you just said in a file designed to store program settings like which side of the screen a toolbar is docked on, then perhaps you should be using one of the full-featured 100% valid XML parsers that are available.

      Or do you think OS writers should also change their design paradigm and force you to re-compile the entire OS whenever you want to enable/disable features?

      Not at all! I much prefer settings to be stored in simplistic XML files rather than binary blob files.

    50. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      I'm not trying to argue that writing an XML parser is going to take thousands of lines of code. I know, that XML parser I mentioned that I wrote, which was tested/certified for compliance, was only 8k in size, and that was written in C.

      I'm just saying such tasks are almost never as trivial as originally thought. Sure, it might take a day or two, or even a few hours to write the initial version, but that initial version is almost always going to have bugs in it, that aren't going to be readily visible.

      You may find that during testing a few months later, that some edge case scenario botches the parser. For example, even with haxml, an infinite loop condition was found in a later revision... Mishandling of certain characters were found later on as well.

      You can try to test your module as well as you think you can, but some bugs just don't rear their ugly heads until you have a developer from another company using your module passing in data that they think is compliant to their interpretation of the spec, which is contradictory or unintended from you the creator of said module. I see it all the time.

      This is why, generally it is usually better to reuse existing libraries than trying to roll your own... For example, I wrote an SDK for a particular spec, and it has since spent 5 years or so proliferating in the community participating in every international plugfest event. Fast forward a few years, and a newby coworker decides to roll their own implementation for a project they are working on rather than to even bothering to look at what is available, and the first plugfest they go to, their device suffers from basic conceptual bugs that I've known about for years. It's like they were starting over again in the learning process when they didn't need to.

      In fact I see it with almost every company that sends a device to a plugfest for the first time. They all suffer from the same kinds of bugs, and go through the same evolutionary path. And the tools/SDKs our company releases, we give away for free and/or give to the opensource community, so I know all about OSS alternatives and such to things as well. So if you're going to recommend using an OSS alternative for something that's one thing, but to encourage a developer to home-brew their own implementation is quite another.

    51. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      and yes, I have seen Microsoft at many plugfest events, so at least they are doing their learning as well... I know of a few companies that release SDKs for such specs, that have never ever sent a rep to a plugfest. Than one day another company brings a device to a plugfest based on said SDK, and on day one, the engineer is trying to figure out why their device doesn't play well with others... Maybe that's why I'm jaded with blind recommendations for 3rd party libraries instead of MSFT libraries, when I've seen instances where such third party libraries are crap. Not saying MSFT libraries are necessarily better, just saying that at least they participate in many plugfest events with their toolkits. (Whether or not they apply patches based on their learnings is another thread)

    52. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      1) Being open source, more eyes are watching for exploits. They can target it as much as they want - I'll trust a project like OpenSSL more than MS Crypto, because a lot of people smarter than I are watching the source and working on it.
      2) Market share. 100% of Windows computers is a very high hit rate. (but perhaps 80% is more realistic) 20% is far, far lower. 1% might not even be worth it, because once you exploit something it's more likely to get patched.

      The number of exploits has climbed with market share for Firefox, OSX, etc., so there's something to be said for sticking with the little guy.

    53. Re:Such dependancies annoy nLite users! by poopdeville · · Score: 1

      My point is that a developer who thinks making an XML parsing library is difficult isn't a very good developer. Bugs always happen, and it is usually a good idea to use libraries that have already gone though the bug fixing process. I do agree about that much. But XML is about as simple a nesting grammar as you can get, and still (almost) generate a Turing complete language (XML lacks a lambda.). Indeed, XML's grammar is formally equivalent to S-expressions, via a trivial syntactic transformation.

      If I want to get REALLY tricky, I can just take a compliant Scheme parser, apply that transformation, and call it an XML parser.

      I didn't say it would take me an hour. I said it would take a day or two. It takes freshmen a week or two to write MULTIPLE S-expression parsers and interpreters. I already know how to do it, so I'm not going to make a horrible architectural choice that destroys comprehensibility or maintainability. (Regular expressions are probably a bad idea, unless you're using them to model Hindley-Milnor and using a structural form very similar to HaXML's.)

      And there were typically 2-3 low severity bug fixes per version, most of which are actually unrelated to XML parsing.

      --
      After all, I am strangely colored.
    54. Re:Such dependancies annoy nLite users! by TheRealMindChild · · Score: 1

      You mention namespaces twice... and the sad thing is, namespaces are a solution looking for a problem (which people intentionally express just to use them). If that is your focus, I don't regard your opinion very highly.

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
    55. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      My point is that a developer who thinks making an XML parsing library is difficult isn't a very good developer. Bugs always happen, and it is usually a good idea to use libraries that have already gone though the bug fixing process. I do agree about that much. But XML is about as simple a nesting grammar as you can get, and still (almost) generate a Turing complete language (XML lacks a lambda.). Indeed, XML's grammar is formally equivalent to S-expressions, via a trivial syntactic transformation.

      I'm not saying it's difficult, I'm saying that if you think that you can get it done correctly in 2 days, you're being arrogant. Haxml started development in 1998. That was 11 years ago. If you look at the change logs, there were still bugs found much later than 1998, that were indeed parsing bugs. I'm not saying that's a bad thing, I'm just saying if it is really so "easy" to develop a compliant XML parser, how come the haxml guys couldn't do it in 2 days? Are you just more brilliant than all the guys that worked/contributed to haxml?

      Besides, the original point of this /. article was talking about windows. I really doubt someone that is writing win32 apps will necessarily be using or be familiar with Haskell.

    56. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      By the way, I'm not trying to be an ass, I'm just going by experience. Using XML as an example, I've gone to a plugfest event that relied on XML where there were > 20 companies in attendance, and almost every company there had errors in their xml handling on their first showing at the event.

      Not necessarily because the parser was flawed, but also because certain assumptions/shortcuts made about the document being parsed were invalid, resulting in interop failures.

      For example, one company was looking at the element name, and wasn't resolving the namespace. They took the literal element name as being (for example) x:foo, and rejected foo and y:foo, even if the default namespace of foo or the defined namespace of y were equivalent to the defined namespace given by x.

      You'd be surprised at the types of shortcuts I've seen companies employ. One company didn't even bother parsing the element names at all, they just did a string search for the element name they were looking for. Other companies assumed the order of the elements were static. etc etc...

    57. Re:Such dependancies annoy nLite users! by shutdown+-p+now · · Score: 1

      You mention namespaces twice... and the sad thing is, namespaces are a solution looking for a problem (which people intentionally express just to use them). If that is your focus, I don't regard your opinion very highly.

      I mentioned namespaces twice because they are most often done incorrectly.

      In any case, you may like or not like them, but they're part of the XML stack. If you say that you support XML - an open standard - then you better support it properly. Otherwise, stick to YAML, JSON, or whatever else you fancy. To be honest, I don't even understand that fad for XML configs in the first place - it's not like you need a lot of interop work there, and it's hardly a most readable format, either.

      If you have a premade parser (like Java and .NET), then it's just saving time, but we're talking about writing one just for the sake of parsing some config files here... YAML would be so much easier to deal with.

    58. Re:Such dependancies annoy nLite users! by greengearbox · · Score: 1

      Would you like to see a fully compliant XML parser, written in a few hundred lines?

      does it

      • auto-detect character encodings?
      • correctly expand internal entity declarations?
      • report namespaces correctly?
      • correctly handle xml:space?
      • default attribute values from a DTD?
      • handle parameter entities?
      • handle external parsed entities?
      • correctly reject characters outside the legal range?

      (some of these are cheating a bit on my part -- namespaces are not strictly part of XML 1.0)

      In general, I agree with you that it's possible to write a fully-compliant parser in a few days. It is far more complicated than most people seem to think, though, and fully compliant XML is not isomorphic to s-expressions.

    59. Re:Such dependancies annoy nLite users! by _avs_007 · · Score: 1

      not that it matters, but I meant 8kb not 8k.

    60. Re:Such dependancies annoy nLite users! by Disgruntled+Goats · · Score: 1

      1) Being open source, more eyes are watching for exploits. They can target it as much as they want - I'll trust a project like OpenSSL more than MS Crypto, because a lot of people smarter than I are watching the source and working on it.

      You mean like all those eyes watching for the bugs in Debian's OpenSSL that didn't discover it for over 2 years?

    61. Re:Such dependancies annoy nLite users! by BikeHelmet · · Score: 1

      2 years is better than never. Heh. ;)

    62. Re:Such dependancies annoy nLite users! by poopdeville · · Score: 1

      I am not trying to be an ass either. I suppose it is true that I am "arrogant". I do, however, think that you can make a workable solution to a simple problem in a short amount of time. As I said, there are already robust XML libraries out there, so choosing one is typically the best choice.

      HaXML has been "in development" for 11 years, but you can be that less than a month of developer time has gone into it. As I said, most of the bugs on the changelog are not related to parsing XML per se, but parsing auxiliary formats. (The DTD shows up in 2/3 of those bugs. DTD's are not valid XML)

      On the other hand, I take a bit of exception to being called arrogant. When I was a mathematician, mistakes were always "allowed", and yet, mathematicians (relatively) rarely make logical mistakes. Why is that? Because mathematical proof is a form of argument that can be read and verified. Because you can read off logical mistakes just by reading the proof. Approaching programming with the same rigor is not difficult. All it takes is mathematical rigor. In fact, I expect it, and am constantly disappointed by the Computer Science flunkies who mess up even simple reasoning.

      Indeed, because of the Howard Curry Isomorphism theorem, you are committed to the position that people are incapable of doing simple mathematics, if you are committed to the position that people can't do simple programming tasks. That much is demonstrably false. People do mathematics, perfectly, the first time, every day.

      Obviously, I have my own thoughts on the subject, but he reason I chose to jump on XML parsing is because the semantics of parsing XML are clear, and can be translated by a machine, either via S-expressions or by parsing the W3C's textual representations of state machines.

      Similarly, making an Oracle SQL parser is ENTIRELY mechanical. Admittedly, that task is a bit more involved, since the grammar is more complex. But that grammar is entirely specified by their own state machine language. But what you want, ultimately, is a program that accepts Oracle's state machine diagrams and renders a parser for the grammar they embody.

      Finally, what you're describing is the worst of all possibilities: poor architecture intended to solve a problem the developer doesn't understand. Bugs can be squashed if the right architecture for a parser is in place. But if you are entirely clueless, and don't realize you need SOME kind of state machine to solve the problem, you're going to re-invent the wheel poorly. I am not surprised to see poor "short cuts". In fact, I am constantly disappointed by computer science flunkies trying to convince me that unit testing is sufficient rigor.

      --
      After all, I am strangely colored.
  9. Obligatory - All Your Base by Anonymous Coward · · Score: 0

    All Your Base - Are Intercepted BY US!
    Set Up Us The Sassle!

  10. Paypal uses an EV cert. by Cerebus · · Score: 0, Troll

    And since the null-termination cert *doesn't chain to an EV provider* it's not much of an exploit, really. No green bar, not safe.

    --
    -- Cerebus
    1. Re:Paypal uses an EV cert. by SomeJoel · · Score: 1

      I'm pretty sure it's the null-prefix that is the issue. Furthermore, if it weren't an exploit, I doubt it would be worth all the hullabaloo.

      --
      <Complete your profile by adding a signature!>
    2. Re:Paypal uses an EV cert. by dopodot · · Score: 2, Insightful

      Do you really think the average user is going to notice a lack of green bar? Internet Explorer is going to accept this certificate as valid for https://www.paypal.com/ and there will be no hints to the user that it's actually illegitimate. Unless there's some other mechanism in Internet Explorer that will notice it got an EV cert in the past and is no longer getting it, then this cert is entirely usable for a man in the middle.

    3. Re:Paypal uses an EV cert. by Anonymous Coward · · Score: 0

      Actually this isn't true, please reference Alexander Sotirov and Mike Zusman's paper "Breaking The Myth's Of EV Certificates." It turns out that all you need is a valid DV cert (like this one) to spoof EV.

    4. Re:Paypal uses an EV cert. by Vellmont · · Score: 2, Insightful


      *doesn't chain to an EV provider* it's not much of an exploit,*doesn't chain to an EV provider* it's not much of an exploit, really. No green bar, not safe. really. No green bar, not safe.

      Have you lost your mind, or are you joking?

      Assuming a rubber room is being prepared for you, I have to wonder why you would think anyone knows to look for green bars.

      I might actually agree with you that this isn't a huge problem, but for very different reasons. MITM attacks are relatively hard to exploit. You're essentially limited to wireless networks, or hostile LANs. Also, this isn't a big deal since if you can already perform a MITM attack there's countless ways to trick the user into thinking the site is secure without even touching SSL.

      --
      AccountKiller
    5. Re:Paypal uses an EV cert. by QuoteMstr · · Score: 1

      Do you really think the average user is going to notice a lack of green bar? Internet Explorer is going to accept this certificate as valid for https://www.paypal.com/ and there will be no hints to the user that it's actually illegitimate.

      There are some things that should be taught in every school in America. Just as there are mandatory classes in sex education and home economics, there ought to be a mandatory class (at least a short one) about basic computer safety. This isn't a complete list, but it's a start:

      • Never type a password into a site unless you see a lock icon in your browser.
      • If you're used to seeing a green bar, and it disappears*, something is wrong.
      • Don't click "ignore" when your computer gives you some gibberish about a certificate. That means something is wrong.
      • Never open emailed attachments.
      • Never click "yes" to dialogs you weren't expecting.
      • Really, there is no prince wanting to give you millions of dollars for nothing.
      • ...No, this particular prince isn't different.
      • The dancing bunny isn't worth seeing.
      • If a site asks you for personal information, ask yourself, "is this the kind of site that would legitimately ask for this kind of information?"

      * browsers should warn about this case.

    6. Re:Paypal uses an EV cert. by QuoteMstr · · Score: 1

      Interesting summary and paper. The gist of it is that EV-validating the main page doesn't help if it pulls in content that's protected by a weaker certificate.

      I can't believe browsers do this. Just like there's a warning when a page protected by normal SSL includes unprotected content, there ought to be a warning about an EV-validated page including non-EV-validated content.

      It's really terrifying how people who really should know better are negligent when it comes to browser security.

    7. Re:Paypal uses an EV cert. by ZosX · · Score: 1

      "Never click "yes" to dialogs you weren't expecting."

      Clearly you have never used Windows Vista.....

    8. Re:Paypal uses an EV cert. by PhunkySchtuff · · Score: 1

      Whilst the above points should be taught at an early age, at present I can only see regular users paying attention to maybe points 1 and 2 above, the others are just more hassle than they're worth (in their opinion)

      I like to consider myself pretty knowledgeable about computers and even I break at least one of those rules (I open emailed attachments)

    9. Re:Paypal uses an EV cert. by radish · · Score: 1

      Well seeing as you're logged into slashdot to post the comment, you probably broke rule 1 :)

      (Sure - maybe there's an https login page for slashdot I don't know about but you get the point).

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    10. Re:Paypal uses an EV cert. by Hyppy · · Score: 1

      MITM attacks are relatively hard to exploit. You're essentially limited to wireless networks, or hostile LANs..

      Just one compromised workstation in a LAN makes it hostile.

    11. Re:Paypal uses an EV cert. by QuoteMstr · · Score: 1

      MITM attacks are relatively hard to exploit. You're essentially limited to wireless networks, or hostile LANs.

      You're also vulnerable to wiretaps, compromised routers, and all kinds of other network malfeasance. Hostile networks are an eventuality, not a possibility.

      this isn't a big deal since if you can already perform a MITM attack there's countless ways to trick the user into thinking the site is secure without even touching SSL.

      Clearly, we need to educate users as well. But that education is futile unless there are real mechanisms diligent users can use to verify their security.

    12. Re:Paypal uses an EV cert. by Vellmont · · Score: 1


      Never type a password into a site unless you see a lock icon in your browser.

      Check.. I saw the lock icon in the browser thingy... the browser is the whole page, right?

      If you're used to seeing a green bar, and it disappears*, something is wrong.

      Check-O! The whole screen is green, that means it's safe!

      Don't click "ignore" when your computer gives you some gibberish about a certificate. That means something is wrong.

      Yup.. no weird message, whole browser green, lock thingies all over the place. I'm safe!

      Never open emailed attachments.

      I NEVER do that.. unless it's from my friend Nimrod. Nimrod always sends out these HILARIOUS videos. You just gotta click the thingy and it all opens up. I'll send you a couple.. you just gotta see it!

      Never click "yes" to dialogs you weren't expecting.

      I NEVER do that either. The computer always tells me what to expect and exactly what to do, so I'm never surprised. These computers! They're always telling me to do crazy things!

      Really, there is no prince wanting to give you millions of dollars for nothing.

      Gotcha! Hold on, I gotta send money for this fedex package that's going to be delivered to me. I'm gonna be a millionaire! Good thing I renewed my car warranty though through that email I got. Just in time, my alternator is about to go!

      The dancing bunny isn't worth seeing.

      Dually noted. I've always preferred growling squirrels. You GoTTA see the jumping kangaroos someone sent me the other day!

      If a site asks you for personal information, ask yourself, "is this the kind of site that would legitimately ask for this kind of information?"

      Duh! I only give out my personal information when my bank or myspace or paypal or someone I KNOW asks for it. I just click on the link that has their name in it any type away!


      This isn't a complete list, but it's a start:

      Getting back to reality here, It's not a complete list, nor could it ever hope to be a complete list.

      You can't teach people a simple set of rules to not get tricked. The tricksters of the world will ALWAYS be one step ahead of any defined set of "rules to be safe on the internet". Those rules will (and have) become superstitions. If you have ANY hope of people being secure on the internet, you have to teach them to be skeptical. Look for the angles. People aren't used to making judgements about things without people involved. They're unfamiliar with automated attacks. Remember that people have nowhere NEAR the knowledge base that you or I do.

      --
      AccountKiller
    13. Re:Paypal uses an EV cert. by Vellmont · · Score: 1


      You're also vulnerable to wiretaps, compromised routers, and all kinds of other network malfeasance.

      Which pales in comparison to the risks of browser exploits, flash exploits, adobe exploits, and even OS exploits. Security risks are relative, and MITM attacks are nothing compared to the other very real, and very much exploited vulnerabilities out their. That doesn't mean this shouldn't be fixed, but it should be put in perspective.

      --
      AccountKiller
    14. Re:Paypal uses an EV cert. by jc42 · · Score: 1

      I have to wonder why you would think anyone knows to look for green bars.

      So what's a green bar? Is it something that a browser does? Where would I see one, so that I can recognize them when I don't seem them?

      I have a dozen browsers installed on this Macbook, and looking around at their windows, I don't seem to see anything I'd call a "green bar" in any of them. So are you saying that none of them are safe? Note even the ones that are showing a page on my own web site (which I've been testing on all the browsers)? ;-)

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    15. Re:Paypal uses an EV cert. by muckracer · · Score: 2, Funny

      > Never type a password into a site unless you see a lock icon in your browser.

      So how'd you log into Slashdot?

    16. Re:Paypal uses an EV cert. by init100 · · Score: 1

      Never open emailed attachments.

      Attachments aren't generally bad, so advising users to never open attachments at all simply denies them functionality that has good uses too. Yes, some file formats can contain malware. Yes, some email applications are (or even more so, were) stupid in assuming that all email senders are good guys. But that shouldn't preclude users from sending emails with attached documents. They should, though, be cautious about opening attachments from unknown senders, preferably ignoring attachments in dangerous formats.

      Yes, it would be nice if people could stop sending bulky attachments through email, but I've pretty much lost hope that this will happen in the foreseeable future. At work, we have a common area on our file servers where people can put documents, but even with company-internal but otherwise unclassified documents, some people seem to much prefer sending a document attached as an email to 20 recipients instead of putting it in the common area and putting a location reference in the mail instead.

  11. this is no bode plot by tach315 · · Score: 0

    We could already predicted new elements whats the big it's not really useful as a tool, maybe a teaching tool. Techniques like the bode plot or smith chart are useful.

    --
    tach315
  12. Update by Hatta · · Score: 4, Informative

    Sounds like PayPal should be freezing everyone's account until this is fixed.

    --
    Give me Classic Slashdot or give me death!
    1. Re:Update by dgatwood · · Score: 3, Informative

      Just anyone who has ever logged in from a Windows box running a browser other than Firefox.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    2. Re:Update by citizenr · · Score: 3, Informative

      Just anyone who has ever logged in from a Windows box running a browser other than Firefox.

      and Opera. Opera uses OpenSSL, thus avoids broken Windows crypto stuff.

      --
      Who logs in to gdm? Not I, said the duck.
    3. Re:Update by thoglette · · Score: 1

      So: which versions of Opera, K-Meleon, etc etc etc actually have the patch. Opera's website is vague, to say the least

      --
      -- Butlerian Jihad NOW!
  13. "...PayPal has suspended Marlinspike's account." by magsol · · Score: 5, Insightful

    Because that is totally going to fix the problem.

    --
    "I'd just like to emphasise that taking a million years isn't a metaphor here..." -Rich Bradshaw
  14. Re:"...PayPal has suspended Marlinspike's account. by SomeJoel · · Score: 1

    Because that is totally going to fix the problem.

    It sure as hell will. They should have done that 9 weeks ago!

    --
    <Complete your profile by adding a signature!>
  15. Re:"...PayPal has suspended Marlinspike's account. by HeronBlademaster · · Score: 5, Funny

    If you don't shoot the bearers of bad news, people will keep bringing it to you.

  16. Microsoft got it right? by Sebastopol · · Score: 1

    FTA :

    "It won't work for exploiting the bug for software written with the WIN32 api, they don't accept (for good
    reason) *!"

    Como?

    --
    https://www.accountkiller.com/removal-requested
  17. Video Of The Defcon Talk by Anonymous Coward · · Score: 3, Interesting

    For more information about null-prefix attacks, the video is here.

  18. No, but by Sycraft-fu · · Score: 0, Flamebait

    If you cause someone grief, don't expect them to be nice to you in return. That's just life. You can be as "correct" as you like, they still have the right to tell you to fuck off.

    If you are an asshole to me, you'll find yourself banned from my house, my websites, etc, etc. Doesn't matter if you feel it was justified, or if you feel that you were "helping the world" with what you did. You cause me grief, you become persona non grata to me. I will not associate with you professionally or personally.

    Same shit here. He's causing Paypal problems, and in fact will probably cost them business. I'm not surprised they aren't interested in doing business with him any more. He is well within his rights to publish about this vulnerability, they are well within their rights to refuse him service.

    1. Re:No, but by Anonymous+Cowpat · · Score: 1

      He is well within his rights to publish about this vulnerability, they are well within their rights to refuse him service.

      They are not, however, within their rights to keep his money. He is within his rights to take them to the cleaners, sorry, courts

      --
      FGD 135
    2. Re:No, but by Anonymous Coward · · Score: 0

      would you prefer he had kept it a secret, sold it to black hats and let them go wild on paypal without paypal finding out ?
      hint: the right approach sometimes means you extend service to people you dont agree with even though they cause you short term pain. its long term gain you should be thinking about.

    3. Re:No, but by QuoteMstr · · Score: 4, Insightful

      AFAIK, the law supports your position. But I really think we need to examine whether that's the kind of society we want. It's perfectly fine for a small business to arbitrarily refuse to have a relationship with a particular person. That person can go elsewhere, and the small business is only hurting itself. But large companies like PayPal are different. They form an integral part of the fabric of modern life. When one of these large companies denies service to an individual, that person's quality of life is reduced without an opportunity for rebuttal, or for a fair judgment by his peers. These companies have become de facto utilities, and just as the electric company cannot turn off your lights because of a personal grudge, PayPal should not be able to arbitrarily cripple your ability to send and receive money.

      When a company gains quite a bit from being large enough to matter in this way; it should give something in return.

    4. Re:No, but by lilrobbie · · Score: 5, Insightful

      From Paypal's justification of their banning:
      "We do not, however, allow PayPal to be used in the sale or dissemination of tools which have the sole purpose to attack customers and illegally obtain individual customer information," the spokeswoman, Sara Gorman, wrote in an email. "We consider whether there is any legitimate use in helping to strengthen the defenses of one's site when determining violation of our policy."

      The problem with your statement is that he did not cause Paypal problems in the way that you think. He showed a widespread security flaw, using Paypal as an example... and Paypal suddenly decided that the tools he was producing "have the sole purpose to attack customers and illegally obtain individual customer information". This is a complete and utter load of bollix.

      So yes, Paypal may not be happy they have a vulnerability... the same vulnerability that every other SSL cert user has I might add... but he was not breaking their TOS. What they did was infantile and very counter-productive.

      This kind of behaviour means the only people that know the flaws in your system are the hackers who want to exploit them for nefarious means, rather than these researchers, who are doing it partially to "help the world", but also to HELP YOU.

      I wouldn't trust a company who discourages security penetration testing and thorough investigations of their systems in these ways. Because you can bet your pants, the black-hat hackers will do their homework and find these flaws if our researchers don't.

    5. Re:No, but by swillden · · Score: 1

      He didn't cause their grief. Microsoft did. He's just an easier target.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    6. Re:No, but by kestasjk · · Score: 1

      Id get worked up about this too except PayPal just has such a terrible record of cancelling accounts. After they've cancelled a fund-raising account for a dead soldier (or something) you become numb to it, they must just be looking for any excuse to cancel accounts and reap the sweet rewards of cash and consumer hatred

      --
      // MD_Update(&m,buf,j);
    7. Re:No, but by maxume · · Score: 1

      I get along just fine without Paypal.

      One reason I don't have a Paypal account is that they are not particularly regulated and pull crazy shit all the time, so I can't see how they are dependable, and having an account doesn't seem worth the potential hassle.

      --
      Nerd rage is the funniest rage.
    8. Re:No, but by GravityStar · · Score: 1

      Debatable. Moxie created the bogus Paypal Cert himself. He didn't release it into the wild, sure. But still, I would expect any person or company to have behave hostile towards people who have created tools to attack that person or company _specifically_. Even if they didn't use them.

      He could just as easily set up a bogus subdomain with SSL and used that to show the vulnerability.

    9. Re:No, but by lordandmaker · · Score: 1

      Since we're being pedantic, that'd be Her Majesty's Revenue and Customs.

    10. Re:No, but by lilrobbie · · Score: 1

      I agree with you that it probably wasn't the smartest hack to demonstrate to an audience of various hackers... but I think that his behaviour, though brash, is not deserving of what Paypal did.

      He could have set up his own domain, but it wouldn't have carried the same weight as proving the vulnerability is present on a major commercial server, where people actually *care* about security.

      Either way, that still doesn't excuse Paypal from their foolishness. If they want to ban him, they need to be honest about why... the TOS quote they used does not match the situation at all.

      On an unrelated note, this kind of behaviour is pretty standard for Defcon. Hackers all tend to go for "showy" approaches to gain peer respect.

      So... foolish of him? Yes. Brash of him? Yes. Something he should have gotten banned for? Definitely not. Was it a useful demonstration? Definitely

    11. Re:No, but by Anonymous Coward · · Score: 1, Informative

      Interesting how you blame MS when GnuTLS, Firefox, KDE, WGet, Mutt and others were/are all vulnerable. This wasn't caused by just Microsoft's handling of SSL certificates, but by rather a lot of other SSL libraries as well.

    12. Re:No, but by Anonymous Coward · · Score: 0

      I wouldn't trust one of these so called 'researchers'.
      And I wouldnt trust paypal.

      I think both side's did the right thing.
      These 'researchers' knew what was going to happen. If they did it, they are 'dumb researchers'.

    13. Re:No, but by swillden · · Score: 1

      Interesting how you blame MS when GnuTLS, Firefox, KDE, WGet, Mutt and others were/are all vulnerable. This wasn't caused by just Microsoft's handling of SSL certificates, but by rather a lot of other SSL libraries as well.

      How does that make this Moxie Marlinspike's fault?

      In the case under discussion, the defect is in code produced by Microsoft. The fact that similar code from other sources may have had the same defect doesn't remove Microsoft's culpability.

      Your comment is like saying "But your honor, even though my client killed that woman, lots of other people have killed other women. Surely you shouldn't hold my client responsible for doing what others have done! We should prosecute the guy who found the body!"

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    14. Re:No, but by sjames · · Score: 1

      Actually, he issued a warning and then some tools that someone else has now used in conjunction with an IE bug to cause Paypal problems. Shall they now cancel Kevin Bacon's Paypal account (only 6 degrees of separation after all).

      Anyone considering Paypal should carefully consider just how much they can trust such a petty (and childish) organization to hold a portion of their money and possibly banking details.

  19. Boy I sure am glad.. by kheldan · · Score: 1

    ..that I closed my PayPal account. :-)

    --
    Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
    1. Re:Boy I sure am glad.. by thejynxed · · Score: 1

      I'm so glad...that any funds in my PayPal account that is basically mandatory use for sites like eBay arrive there via disposable Debit/Credit cards from Visa, etc. I never put in more than the cost of the item, the account is not tied to any of my personal accounts, and if I happen to sell something, as soon as the money appears I remove it from the account.

      --
      @Mindless Drivel: 100% of Twitter posts ever Tweeted.
  20. Re:uber lolz by Anonymous Coward · · Score: 0

    I would so love to see some of the paypal directors in prison

    Why are you in prison?

  21. Re:uber lolz by spartin92 · · Score: 2, Informative

    No, paypal is just fine. The problem is that Microsoft has not updated its encryption API for Internet Explorer to stop a publicly known exploit for SSL.

  22. Shooting whom? by eyepeepackets · · Score: 4, Funny

    Kirk: How is the messenger, Bones?

    McCoy: He's dead, Jim.

    Kirk: Well, I suppose our mission here is accomplished.

    McCoy: Yes, I suppose you're right.

    --
    Everything in the Universe sucks: It's the law!
  23. Re:"...PayPal has suspended Marlinspike's account. by dfay · · Score: 1

    If you don't shoot the bearers of bad news, people will keep bringing it to you.

    Awesome. This is a quote I'm going to remember for a long time!

  24. Was he really causing them grief? by namespan · · Score: 1

    If you cause someone grief, don't expect them to be nice to you in return

    Was he causing them grief, really? The vulnerability existed whether he talked about it or not. Given that it's tied to some deep long-term issues with null-terminated strings, it's entirely credible to theorize that there are black hats that knew about it already, and his disclosure gave software developers a chance to do something about it. That keeps PayPal from having to deal with fraud and theft problems associated with the vulnerability. Hardly assholery.

    And even if they're within their rights to behave this way, it's more troubling than the existence of vulnerabilities. Everybody makes mistakes, but retaliation every time anyone points one out doesn't build trust, it makes you look insecure and calls into question your ability to improve. How much do *you* trust a company whose response to criticism is to lean on those who level it?

    And all this leaves aside the ethical issues inherent to any kind of retaliatory cessation of service. Losing your PayPal account isn't such a big deal, but there are other services for which this kind of behavior would grant heavily inequitable power to providers, particularly in markets where there's a small number of competitors or where the idea of blacklisting takes hold. It's one of the reasons why libertarianism will never, ever work anywhere near like its proponents like to imagine it will.

    --
    Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
  25. ow, retaliate! by Onymous+Coward · · Score: 5, Insightful

    If you cause someone grief, don't expect them to be nice to you in return.

    Look at it this way: If a doctor jabs you with a mortally-needed anti-venom needle, do you have the right to tell him "Fuck off!"?

    I suppose... "He caused me grief!" Yeah, okay. It's a bit of a simplistic metric, really, for determining what is a good response. Appropriate for a young child or a retard. Maybe not for a large corporation. Hopefully not for you.

    It does matter what the person's intentions were.

    1. Re:ow, retaliate! by Score+Whore · · Score: 0, Flamebait

      Look at it this way: If a doctor jabs you with a mortally-needed anti-venom needle, do you have the right to tell him "Fuck off!"?

      Can you please tell us what exactly Paypal is going to do here? Seriously. WHAT. DO. YOU. THINK. PAYPAL. IS. GOING. TO. DO. ABOUT. A. BUG. IN. MICROSOFT'S. SOFTWARE?

      If you want to make an analogy try this one:

      Bob makes a walkway over a thousand foot drop and puts a nice rail on it.

      Some twit, say, Cowymous Onward, comes along and says "if someone presses against this rail in just this place, in this peculiar body position, they can slip through and die."

      Bob considers this and sits down to fix the problem in a robust and well thought out manner.

      The next day, Cowymous Onward happens to be on the walkway and notes that it hasn't been fixed. In moment of absolute fucking brilliance, he decides to demonstrate the nature of the problem. He begins grabbing the school children, who happen to be visiting the walkway, and after twisting their arms back just so, and pushing their right leg out just like this, shoves them one by one through the railing to their death.

      So tell me, who is the complete twat: The school children for using their last moments of life to think "gosh, that dude sure was an asshole." Or Cowymous Onward for deciding to cause substantial grief for an unrelated third party whose only "crime" was existing and being near the walkway.

    2. Re:ow, retaliate! by AK+Marc · · Score: 1

      Can you please tell us what exactly Paypal is going to do here? Seriously. WHAT. DO. YOU. THINK. PAYPAL. IS. GOING. TO. DO. ABOUT. A. BUG. IN. MICROSOFT'S. SOFTWARE?

      What should they do? Either ban all browsers that identify as those affected, or make a public statement that they will cover the costs of fraud. They are a business. The system they and/or their customers use is broken. They should find the browsers that identify as the affected ones and serve up a page pointing to Opera or some other browser not affected. Perhaps even a link to OSs that don't have the problem and a suggestion of moving to a more secure system.

      Instead, their response is to not inform anyone that they are at risk and attack anyone that reveals that there is a risk. The risk can be easily eliminated by changing browsers, and less easily eliminated by changing OSs. Yet, such checks and suggestions aren't made. If PayPal was very serious about security, they'd come up with a test (rather than relying on browser self-reporting) and block access to their site by anyone running affected systems. Though even that wouldn't prevent the problem, as people affected and the victims of a valid man in the middle attack would never make it there. So informing all users to abandon browsers that rely on Microsoft's broken security would be an appropriate course of action.

      So tell me, who is the complete twat: The school children for using their last moments of life to think "gosh, that dude sure was an asshole." Or Cowymous Onward for deciding to cause substantial grief for an unrelated third party whose only "crime" was existing and being near the walkway.

      You analogy is crap. CO didn't push anyone, he just pointed out a flaw. Bob made the rail, and Paul bought the rail and installed it. Bob may or may not at some future time work on the rail and fix it, but hasn't yet and we don't know when he will. Paul could replace the rail with one made by someone else, but that's a cost when it's Bob's fault, even if they are the ones using it. So Paul, knowing there's a deadly flaw, doesn't tell anyone because they'd stop paying him to walk across the walkway. Instead, CO happens to see what is happening (not just the flaw, but the politics around it of people failing to address or even acknowledge that it's serious). So CO sits at the end of the walkway saying "don't go there, it's not safe." So, if your wife were to push you through the broken rail to your death, would you blame Bob, Paul, CO or your wife? Paul asserts CO is at fault for informing your wife that it was unsafe so she could exploit it.

      Bob should fix it or recall it. Paul should inform everyone walking across that it's unsafe. CO should be lauded by the public for protecting them from Bob's incompetence and Paul's negligence. And you should stop walking near your wife when over thousand foot drops.

    3. Re:ow, retaliate! by cdrguru · · Score: 1

      I haven't seen exactly where it is documented what operating systems are not affected by this. I would suspect that most are, and by design all should be. If a null prefix is valid, then it should be accepted. If it is not valid, then it is the same level problem as a CA that issues a certificate for anyone without proper authentication.

      Further, if all operating systems other than Windows are not affected by this it doesn't really matter. 90% or more of PayPal's customer base is using Windows. Recommending in some pedantic manner that the user should change operating systems is pointless - most users are incapable of changing without buying a new computer. I'm sure PayPal would like to assist them in that purchase but that isn't the point. And if the problem is in Windows a different browser isn't likely to make any difference at all.

      This isn't a PayPal problem. It is a world at large problem. Certificates formed like this are an attack on the trust of the Internet. With this being possible, there is no assurance that any certificate is valid anymore. Pretty much, we have CAs issuing certificates without proper validation. That trashes everyone.

    4. Re:ow, retaliate! by AK+Marc · · Score: 1

      Recommending in some pedantic manner that the user should change operating systems is pointless - most users are incapable of changing without buying a new computer.

      Which is why I said they should recommend changing browsers. However, you pretended I didn't say that, and instead attacked the "high security" response. And we know that high security is often no security because people won't do it (like not writing down 16 character passwords that can't contain dictionary words and must include upper, lower, special and numbers just doesnt happen).

      This isn't a PayPal problem. It is a world at large problem.


      Well, good to know that ti doesn't affect PayPal. Since it isn't a PayPal problem, it doesn't affect them, right? Or are you saying that if there is a problem that directly affects you, if you could fix it, but instead set up a trail of blame, it isn't your problem anymore?

      Certificates formed like this are an attack on the trust of the Internet.

      And the attack wouldn't succeed if the browsers had proper input checking, and IE doesn't because it hands that part off to the OS and the OS is broken. However, browsers like Opera don't use the Windows SSL functions, so it doesn't require an OS patch (rewrite?) to fix. They can't ix the CAs, but can affect the browsers used at their site.

  26. How does this work (in 20 seconds) by Monkier · · Score: 5, Informative

    what usually happens:
    * you request a cert common-name=serverbox.mydomain.com from a Certificate Authority (CA)
    * CA determines you are authorized to make this request on behalf of mydomain.com
    * serverbox.mydomain.com serves down the signed cert, your browser makes sure website == common-name == serverbox.mydomain.com

    what these clever guys discovered:
    * you can request a cert common-name=paypal.com\0.mydomain.com
    * CA determines you are authorized to make this request on behalf of mydomain.com
    * man-in-the-middle sits in between you and paypal.com, serves down this cert, victim's browser makes sure website == common-name == paypal.com (whoops!)
    * victim sees paypal.com in their browser with that reassuring padlock

    1. Re:How does this work (in 20 seconds) by tokul · · Score: 2, Interesting

      victim sees paypal.com in their browser with that reassuring padlock

      paypal.com uses EV cert. Original site shows green location bar.

    2. Re:How does this work (in 20 seconds) by Anonymous Coward · · Score: 0

      does ie6 has EV support?

    3. Re:How does this work (in 20 seconds) by Hurricane78 · · Score: 1

      CA determines you are authorized to make this request on behalf of mydomain.com

      That part is just wishful thinking.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    4. Re:How does this work (in 20 seconds) by cdrguru · · Score: 1

      So where is the CA that will issue bogus null-prefix EV certificates?

      I would think www.bankofamerica.com would be a lot more interesting than www.paypal.com

  27. Re:uber lolz by Culture20 · · Score: 1

    So paypal violates their own privacy policy by not using working encryption

    There is absolutely nothing wrong with Paypal's encryption. There is nothing wrong with the CA that paypal uses for their SSL cert. There is technically nothing wrong with the CA that allowed a null-prefixed SSL cert to be created, although they were stupid to do it. Microsoft needs to fix their ^$@&#.

  28. Re:Idiot or Shill by machine321 · · Score: 1

    But I'm using a 64-bit OS, you insensitive clod!

  29. Re:"...PayPal has suspended Marlinspike's account. by Anonymous Coward · · Score: 0

    That's just the first step. If the exploit isn't gone in a few days they'll try harder measures, like prank calling his house, and ringing his doorbell and running away before he answers.

  30. escape-characters poorly misunderstood by durnurd · · Score: 4, Informative
    I'm rather fond of this bit of ignorance:

    The certificate is the latest to target a weakness that causes browsers, email clients, and other SSL-enabled apps to ignore all text following the \ and 0 characters

    --
    --Edward Dassmesser
    1. Re:escape-characters poorly misunderstood by Anonymous Coward · · Score: 0

      I'm rather fond of this bit of ignorance:

      The certificate is the latest to target a weakness that causes browsers, email clients, and other SSL-enabled apps to ignore all text following the \ and 0 characters

      lmao

  31. This is a scary scenario by misnohmer · · Score: 2, Insightful

    Since the hole affects Windows Crypto API's, this should now be easily possible. A rootkit virus, which hijacks all the traffic from its local network, intercepts all windows update requests and spreads itself as an update. Implications: if single machine on your network is infected, all windows machines get infected within 24hrs? This is providing you can get a code signing cert with null-prefix, but I don't see why this would be much different than SSL cert (just find an automated CA).

    1. Re:This is a scary scenario by Zaiff+Urgulbunger · · Score: 1

      I think someone mentioned above that Windows Update can't be affected by this for some reason. Never-the-less, I guess this would still work for any updates outside of Windows Update.... so iTunes/Chrome/Firefox/whatever that tries to update itself over the interwebs could be affected perhaps?

    2. Re:This is a scary scenario by misnohmer · · Score: 1

      The sslsniff tool already offers this capability for Mozilla and Firefox/Thunderbird add-ons. Even the howto is included for those who lack the expertise. From the sslsniff page:

      sslsniff has also been updated to support the OCSP attacks that I published at Blackhat 09 and Defcon 17, thus making the revocation of null-prefix certificates very difficult. Additionally, sslsniff now supports modes for hijacking auto-updates from Mozilla products, as well as for Firefox/Thunderbird addons. Attackers can specify payloads of their choice, which will be delivered to the targets being man-in-the-middled.

  32. escape-characters poorly misunderstood? by YesIAmAScript · · Score: 3, Funny

    I dunno, they seem fully misunderstood in this case.

    --
    http://lkml.org/lkml/2005/8/20/95
  33. You mean like SSH does? by argent · · Score: 1

    I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes.

    You mean like ssh does? Yes, I've been arguing for this for years. But there's no money to be made there, so it won't happen.

  34. http://www.thoughtcrime.org/ by Agamous+Child · · Score: 2, Interesting

    Did anyone else read the stuff this kid has on his site? Moxie is a Sailor/Hacker/Anarchist/Squatter/Hitchhiker enigma. Holy shit this kid has sailed the CA coast in the worst conditions alone. I am duly impressed and green with envy and depressed that I am not living a life like his.

    --
    I had a sig, but /. ate it. My Web Site
  35. Re:Update - Ebay & Paypal do not value reports by Anonymous Coward · · Score: 0

    Paypal or Ebay do not care if you do any good to them.

    At some point about a year ago when Ebay was changing their website I noticed a vulnerability that would show
    any user's e-mail address. Spent nearly 2 hours trying to explain it to their "tech support" idiots. Finally, after
    being transferred from one person to another on their support chat - they escalated it and the loophole was fixed
    in less than 12 hours...

    Now, I have several accounts with Ebay. One has nearly 100,000 feedbacks. Another one had 10,000 and had
    a small problem with one product thus more than usual customer complaints. It was suspended. Eventually,
    I looged in into my dad's account from the same IP to help him buy something, and they suspended his too.

    I got rather angry and upset. Called them and asked to reinstate all the accounts. The response I got was
    something similar to "sorry sir, you violated our policy". It's been about half a year since then. I moved away
    from Ebay and selling much better with other means. The fact that their entire user database with email
    addresses could have been stolen by blackhat hackers would I have not disclosed them the issue did not
    seem to interfere with their decision process on the "policies".

    As such, just as Marlinspike may be somewhat upset that he only did a good thing and got suspended, I am
    largely pissed off. And if I ever find anymore problems with Ebay or Paypal, I will not disclose it to their
    tech support since I do not feel they value such reports. In fact, I feel just the opposite.

  36. You've read Fenyman on security, right? by Anonymous Coward · · Score: 1, Informative

    Fenyman went to visit a General in his office one day.
    It seems the good professor liked to tinker with locks, and while there tinkered and found, unbeknownst to the General, the combination to the General's safe. The next time he happened to be there, something was needed from the safe, and the General was astonished when Fenyman said "...let me get it for you" and proceeded to unlock the safe and retrieve the item. He explained to the General how the lock on that type of safe was easily broken, and not to be trusted. Time passed. Feynman visited the General's office again and while waiting, noticed a memo posted in the Office. "It is prohibited to let Dr. Feynman near safes..."

  37. What happened to "Praypal" meme by Mathinker · · Score: 1

    I vaguely remember a wave of anti-Paypal protest and an anti-Paypal meme using the meant-to-be-pejorative take-off name "Praypal". But now when I search for "Praypal" on Google I only get legit "find someone to pray with" (and similar) sites. Did I miss some kind of meme revolution, there?

  38. Not just a windows problem by js_sebastian · · Score: 1

    The problem is that this is not just some buffer overflow where you can replace single function call with an equivalent function call that does a safety length check. Security holes that depend on '\0' characters in strings exploit a systematic flaw in the Windows API design: the mix of two entirely different and incompatible types of strings all over the place. The 'native NT' API uses Unicode strings with an explicit length, but the Win32 API and C/C++ libraries usually use null-terminated strings.

    Who cares about their dirty (or not) implementation details? The \0 in certificates trick is a bug that was present pretty much all over the place, not just in windows. If you are an ubuntu user and you read the description of security updates when they are pushed to you, you will have seen mention of this bug in at least a dozen different updates already. Hell, today there was one for wget! I agree with the grand parent poster: taking so long to fix this on windows is inexcusable.

    1. Re:Not just a windows problem by DavidTC · · Score: 1

      No kidding.

      This \0 nonsense demonstrates two things:

      1) All products have security holes. Often near identical ones, especially if it's an implementation detail no one ever considered before. (I remember, in the old days, OS after OS kept getting hit with TCP/IP attacks using various malformed packets.)

      2) Microsoft takes way too long to fix their security holes.

      --
      If corporations are people, aren't stockholders guilty of slavery?
  39. What are you talking about? by benjymouse · · Score: 1

    For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database.

    In fact, ASP.NET has some very sensible options for addressing this issue. Take for example the (infamous) DataGrid. In DataGrid you define columns. The column to "bind" to a datasource (database/collection/etc) is called BoundColumn. It has a property called HtmlEncode. It has a default value of true . Which means that contrary to your claim, if you use this "data binding" control, ASP.NET *will* encode data bound text by *default*

    The Literal control is just that. It defaults to displaying literal text. However, it *also* has a property so set whether to pass-through, encode or translate html.

    It is true that some controls (like e.g. RadioButtonList) do not support encoding the *text* property. Those controls render in a way where you should never set anything but plain text anyway. If you were binding HTML text to radiobutton lists, checkbox lists or select controls I suggest you take a good long look at the requirement instead.

    The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode.

    Sorry, but that is just stupid. You should simply have set the encode property of the control you were binding to instead. If you were binding to a control which did not expose such a property, maybe you should have used a control which did?

    If you've only ever written a single ASP.NET application, perhaps you refrain from making bold faced criticism on a subject where you are obviously not qualified.

    Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.

    No, it will not be fixed, because it is a feature, not a flaw. This is a case of an unexperienced developer misunderstanding the framework and failing to use the correct components. But there's a fix for that, too.

    --
    Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
  40. Suspending is childish by logfish · · Score: 1

    Suspending his account is the most childish thing in the history of stupid that the PayPal.com people are currently writing.

  41. paypal account by wren337 · · Score: 1

    So if you're a hacker who relies on PayPal, the not-so-subtle message is to make sure your projects steer clear of your online payment processor.

    We call this the "don't sh*t where you eat" principal.

  42. Webkit/Chrome win32/64 must be updated very fast by Ilgaz · · Score: 1

    I understand they wanted to stay with native OS functionality as long as possible, especially on Windows which they were critiqued for not shipping "native" stuff but we now see the result.

    I think Webkit/Safari/Chrome must move to OpenSSL as quickly as possible.

    This locate output should explain why I am really surprised by them not using openssl instead, like Opera does: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/openssl

    Apple knows OpenSSL and uses it all over the OS. I don't believe OS X can even boot/browse without it.

  43. I'm glad by Anonymous Coward · · Score: 0

    that Paypal axed the hackers account, I'm tired of these idiots trying to make off with other peoples hard earned money. Why doesn't he get a job like the rest of us?

  44. MSDN even explains how to prevent this hole by Anonymous Coward · · Score: 0

    http://msdn.microsoft.com/en-us/library/system.string.aspx has a nice little warning under the heading "Strings and Embedded Nulls" about what the API's coders should have done to prevent these mixed string types from causing security holes...

  45. Doesn't work in Vista, W7 by SigNick · · Score: 1

    I created and deleted the directory without any problems in Vista SP0, SP2 and Windows 7.. those who modded you up - on which system did this trick work? You did test it, right?

    BTW to disable creating the useless short file names in order to slightly improve performance:
    Set NtfsDisable8dot3NameCreation to "1" in \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem and reboot to finally get rid of the cruft from the early 90's.

    --
    Capitalization is the difference between "Helping your uncle jack off a horse" and "Helping your uncle Jack off a horse"
  46. Re:uber lolz by dissy · · Score: 1

    That is the reality. But read what paypal is claiming, which is not that at all.

    Paypal disabled the security researchers account for distributing software which they claim has no other use than hacking paypals encryption.

    You and I know what is actually going on, but personally I refuse to use that as an excuse to let paypal out right lie about the reasons of their actions, and their press releases.

    P.S. Repeating what paypal announced is trolling?

  47. Re:Idiot or Shill revisited by omb · · Score: 1

    After two (-1) troll moderations it is clear the M$ astroturf gang dosnt like the truth and clarity and is much happier with market speak, so,

    to add to the clarity, this was entirely M$ making because they were too lazy to check the CN properly when parsing the CERT in the Windoze (TM) CAPI. OpenSSL and thus Linux and MAC do not suffer from this bug!