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.
...it is thought that more people are going to be using Macs' and Linux in the future.
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.
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)
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.
Moxie Marlinspike - that's a goblin name if I ever saw one.
a bug or a feature?
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....
This has to be the worst advice I've ever heard.
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.
NO! Don't roll your own crypto. This is madness!
*Kicks BikeHelmet into pit*
OpenSSL is available for windows; use that.
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!>
Sounds like PayPal should be freezing everyone's account until this is fixed.
Give me Classic Slashdot or give me death!
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
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!>
If you don't shoot the bearers of bad news, people will keep bringing it to you.
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
For more information about null-prefix attacks, the video is here.
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
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.
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.
..that I closed my PayPal account. :-)
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
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.
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!
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
*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
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
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:
* browsers should warn about this case.
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.
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"
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.
"Never click "yes" to dialogs you weren't expecting."
Clearly you have never used Windows Vista.....
zosxavius photography
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!
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.
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)
Specialist Mac support for creative pros, Melbourne
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.
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.
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.
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"
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.
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. :/
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.
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.
What makes you think your own code is any better?
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.
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...
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
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.
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.
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 ^$@&#.
You're also vulnerable to wiretaps, compromised routers, and all kinds of other network malfeasance. Hostile networks are an eventuality, not a possibility.
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.
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
But I'm using a 64-bit OS, you insensitive clod!
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.
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.
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);
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.
--Edward Dassmesser
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).
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.
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
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.
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...
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....
I dunno, they seem fully misunderstood in this case.
http://lkml.org/lkml/2005/8/20/95
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.
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.
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.
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.
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.
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
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!
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..."
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.
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.
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.
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?
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.
> Never type a password into a site unless you see a lock icon in your browser.
So how'd you log into Slashdot?
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.
Since we're being pedantic, that'd be Her Majesty's Revenue and Customs.
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
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. ;)
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... :/
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.
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.
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.
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*
Suspending his account is the most childish thing in the history of stupid that the PayPal.com people are currently writing.
> 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.
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.
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.
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.
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.
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.
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"
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?
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.
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.
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....
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.
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?
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?
> 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.
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.
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.
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. ;)
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...
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.
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.
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)
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.
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.
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
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?
/. article was talking about windows. I really doubt someone that is writing win32 apps will necessarily be using or be familiar with Haskell.
Besides, the original point of this
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...
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.
Would you like to see a fully compliant XML parser, written in a few hundred lines?
does it
(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.
not that it matters, but I meant 8kb not 8k.
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!
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?
2 years is better than never. Heh. ;)
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.