Slashdot Mirror
Security Vulnerability in Microsoft .NET Passport
Stuart Moore writes "A vulnerability was reported in Microsoft .NET Passport, also affecting Hotmail user accounts. The simple flaw allows an attacker to change any person's password to an arbitrary value. The attacker can then gain access to the victim's accounts, as well as to the victim's personal information (if any is stored w/ Passport). Muhammad Faisal Rauf Danka posted a note to the Full-Disclosure security e-mail list after multiple unsuccessful attempts to contact Microsoft." There's a news report as well.
Sooner or later they'll start blaming users for providing personal information, and excusing websites and companies from security flaws.
My neighbor's
Microsoft make an interesting interpretation of RFCs by accepting all mail to postmaster@ but only insofar as to send an automatic response saying your message will not be read.
This guy also says he tried to email them ten times and never got further than automagic autoreplies. Do they actually have a procedure to inform them when things are broken?
There is an outlined procedure for this sorta thing...
In the event a user discovers an exploit, inform user to reboot machine and it will go away.
But seriously, there seems to be no OFFICIAL way for end users to actually contact microsoft, nor any sorta automated system to rank e-mails based on importance, nor any human within the phone network who actually knows who to talk to. People who i've known that worked there also have no clue as far as who to talk to, and admit this if you're lucky. If you are unlucky, just say it's a vender issue without thinking the vender is Microsoft.
There is no sanctuary. There is no sanctuary. SHUT UP! There is no shut up. There is no shut up.
I usually stand up for the Redmond boys if there's some bashing going on and not alot of balance to the issue. But this is just an incredibly stupid hole to have open. Why would you ever, ever, ever pass details in the URL string that the user himself need not (and should not be allowed to) supply? If it is because you are passing it among servers in some fancy-schmancy web service scheme, then at least have the decency to hide the exploitable name/value pair in an http header or something (but even this should not be necessary for what they are doing , even if my guess as to how their backend works is wayyy offbase). Somebody said it earlier in the discussion that it is because developers (using the term lightly) add features without thinking of how to do it right and how to do it securely and just pass any old thing in the URL string, and they were right on the mark.
Some coders (again using the term loosely) at my organization used to do this absolutely all the time and I would bitch about how piss poor it was from a security angle (and regularly demonstrate how easy it was to circumvent the intended "security" mechanisms). Everybody laughed at me when I did... that is until one of our largest customers hired an outside firm to audit the "security" of the apps they were getting. It took the firm very little time to discover these nuggets, of course. It is interesting to note that they reported that the application security was among the poorest they had seen, but that the server configurations (my department) were among the tightest. The sad thing is the stupid customer basically thought the two canceled each other out, threw some extra money at redesigning the application to meet the standards it should have to begin with, rewarded our systems team which had done it right the first time with absolutely squat, and renewed the contract for another five years. Shows you how much the corporate world understands what's really going on.
Can I bum a sig? I left mine at the office.
If you've made any study of it at all you know that effective security results from a process that starts before the software is even written. There is no protocol that will save you from logic errors (like the latest Passport hole). To do this reqires a good understanding by the devs of security and their adherence to design principles and coding practices. To do that you need a software development methodology that enforces the consistent application of those priciples and practices. Therein lies the problem.
In my little corner of MS (though by all accounts it was typical of the company as a whole) what was prized above all was meeting requirements and deadlines. Virtually no energy was put into the development environment (hence the hour I spent every morning just downloading the nightly build, the insane .bat scripts, constantly fixing my own NT install as a $55/hr contractor). Nobody got "c-hours" for making life easier. More importantly, there was little value placed on design, good technique. Lip service was paid in meetings and reviews, of course, and superficial style details received obsessive scrutiny. Code reviews often bogged down on correct hungarian notation but a unit test consisting of "return true" was perfectly ok. The "heros" were people with big brain muscles who spent nights and weekends hammering out code to meet the latest deadline.
The result of all this was a coding culture that I called the kingdom of cut-and-paste. I was actually encouraged to write routines by starting with someone else's routine to do something unrelated and edit it to do my task. A colleague would stand over my shoulder browsing the codebase looking for something convenient to steal. It was a shock to realize how little code people actually wrote. This is one of the things that I hated about working there, that I spent so much of my time fscking with the various APIs, incomprehensible include file heirarchies and so little time writing C++.
Well, in my Intro to Fortran class in '77 the prof explained why massive code duplication is a bad idea, and the results are visible in every MS product. You can't fix a bug in one place, you have to fix it every place it got copied to, and you don't know where those are. The codebase is now on the order of 100'sM lines or better? Probably not even MS has a good handle on this, because they can't know for sure how much duplication (with tiny variations) there is (clue: lots).
Once a company grows to a considerable size it's really hard to change the culture. I've seen this at several startups. MS is like a battleship or an aircraft carrier. High-tech and deadly but turning that boat around is really hard and simply may not happen in a short distance. Expecting them to change their performance WRT security in a few months (or year) is kind of like expecting the old Soviet apparatchiks to start respecting civil liberties and human dignity because the Central Comittee sends out a memo. Good luck. It's a city unto itself in Redmond, its own little world. And even if you did, what the hell are you going to do about the millions of lines of (largely incomprehensible) code in the installed base? The millions of systems in the wild that are unpatched and unmaintained?
I see many of the same disasters being recapitulated in .NET. They may talk security and I'm sure they're trying hard but I expect that their long term strategies are going to rely more on legislation than the (probably impossible)
task of bringing their products t