Slashdot Mirror
MS Giving Exploit Writers Clues To Flaws
In the IT trench writes "How's this for a new twist on the old responsible disclosure debate? Hackers are using clues from Microsoft's pre-patch security advisories to create and publish proof-of-concept exploits. The latest zero-day flaw in the Windows DNS Server RPC interface implementation is a perfect example of the tug-o-war within the Microsoft Security Response Center about how much information should be included in the pre-patch advisory."
I know the ongoing debate about whether open source or closed source has the security advantage when it comes to exploits in code.
But this is a case where a half-and-half approach is probably the worst of all.
Umm, do these people really think that hackers can't reverse engineer a patch and see what it's doing??
.. because they will have no idea what the patch is doing and if it will affect other stuff they have. Also, this will be an excuse to further delay the release of patches, since now it will have to go through even more QA.
.. now that's funny.
IT admins will be the most affected
Hackers that RTFM
It would have taken an open source project longer to write the security advisory than to change 1 line of code (or 2 tops) to fix the stack overflow issue.
How hard is it for Microsoft to push out a new update for a change this minor (and important)?
This is a critical problem for any intranet (Universities come to mind as the largest target) running Microsoft servers. And it can also affect a whole load of dedicated servers running the basic versions of Microsoft server software.
What are they waiting for?!
I seem to remember that one of the reasons XP was cracked was that the Windows XP team responsible for it gave an interview about it. They were so proud of it that they gushed about the nuances of it. Now, they didn't exactly give a lot to technical detail but they gave enough to crackers to figure out how it worked. Pretty soon there was a key generator program released.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Maybe they should do what Mozilla does, which is to "hide" vulnerabilities until they either patch them or feel that a sufficient number of people have applied the patch (which is of course the other problem). Of course, like with Blaster for example, you can release a patch and 30 days later the exploit nails all the people who didn't bother to fucking patch.
I can see some people's heads exploding with this one.
It tells me, as an administrator, what to be suspicious of, rather than some secret bug they are patching.
Now, it's true that it is still in the favor of the virus writers in that hardly 100% of sys admins keep up to date on this stuff (wheres the time?) but it is scary that they can exploit a specific bug base on a vague explanation in the first place..... (scary in that Windows is really that bad...)
That's great. Now they have an excuse to be incredibly vague about the problem in the advisories. It will be like the Government and National Security Letters.
"We need you to submit to this, to protect you from hackers. We can't discuss the issue as it's a trade secret and a threat to computing security. This is a critical venerability. But we can't tell your why. Just install this patch when it comes out and you'll be better. Trust us, we know what we're doing."
Microsoft should pre-publish a whole bunch of tasty looking security advisories that are 100% fake every time they publish one that is real. Make them the most enticing looking (remote code exploit with unvalidated input overflow in ssh). Any given cracker will probably pick the fake and quickly waste gobs of time.
If they wanted to get more diabolical, they could even put some honey pots into the code itself. For example, something that emulates a buffer overflow crash when a certain malfromed word is injected. Or maybe something more tantilizing but useless like a 1 second pause in Internet explorer when a certain tag combination appears followed by a page reload to make them think IE just belched but managed to somehow recover. Hint at this in the pre-pub or leak it on the web (post it in a slashdot comment). they can validate it's existence so they believe the bug really exists too.
Each time they patch the real security hole they can preload ten new honeypots for the next round of spoofing the hackers and eradicate the old ones so it looks like they are patching real bugs and the hackers never catch on.
Why am I posting this under this parent? Well because you could only get away with this in closed source. Open source would make this a give-away.
Some drink at the fountain of knowledge. Others just gargle.
One could find exploit code to the DNS issue before the advisory was published. MSRC didn't reveal any more information than was already publicly known.
I actually think that MS pushes out some patches too fast. My Windows laptop gets autopatched and the problematic parts of the system (wireless networking in particular) sometimes get screwed up for a while until the next patch set arrives. I don't think that MS is responsible for all the breakage. Often, MS makes a change which can break an existing driver or app. From a user's perspective all that you see is that a MS patch breaks the system.
Engineering is the art of compromise.
Parent is right - the DNS RPC flaw is a 0day issue discovered in the wild. It was reported to Microsoft, apparently by TippingPoint and the Zero-Day Initiative. That is why they released an Advisory (something they usually only do for issues discovered in the wild).
Put another way - it was actually initially discovered by the black hats, and an exploitation tool released and used, not confidentially reported to Microsoft under the "Responsible Disclosure" programme, or even publically posted to somewhere like Full-Disclosure.
The article is talking obvious stuff. Obviously lame stuff. Just saying "There's a flaw in the RPC management protocol of Windows' DNS server" is enough to clue you in, because the bug is sitting in about the first place you'd look, a nice juicy classic stack overflow. That's also absolutely critical information that is required to effectively mitigate the attacks in the wild before they get any worse, and mitigation shouldn't normally be a problem (RPC management of DNS isn't that widespread).
As a black hat, guessing details of upcoming patches by looking at the pre-patch advisories is a poor idea:
1. They'll be patched, and not even a week later if you're looking at the regular notifications. That's a pretty limited timeframe to exploit the bug.
2. Even worse, MS can push it out early if they really have to, because generally by that time the patch has already been completed for a month or so and is, in fact, sitting in testing (go ahead, check the dates on the digital signatures if you don't believe me). And the development/fixing QFE branch is quite a bit ahead of the stable GDR branch. Sometimes you find that by analysing the differences between them, interesting changes pop up.
You're better off looking at past exploits and trying variations on them, because MS have a habit of incompletely fixing a bug by fixing one code branch, but missing another closely related one on the very same page. For example, patching a length buffer overflow in the first ANIH chunk of a RIFF file, but forgetting they have another parser (that hasn't been patched) for handling subsequent ANIH chunks. (If this sounds familiar now, it should.)
You're even better off looking for novel exploits in the old-fashioned way; target any code that parses or handles data in any form that you can manipulate, figure out which of the potential targets represents the juiciest opportunity for a vector, and start either disassembling and looking for oversights, or blindly fuzzing boundary conditions and trying to make it break.
In that way you can stumble upon entirely original high-value exploits that bear little similarity to an existing issue and so are unlikely to be picked up by AV signatures or IDS until after the exploit is fairly well known or unless it hits one of the larger honeypots like dshield and they figure out what's going on.
Let us take a look at the recent topic of a Madwifi vulnerability affecting certain wifi users in Linux.
Julien Tinnes reported it at 13:48:00 EST on December 7, 2006.
At 14:17:50 on the same day the patch was available in the main source code repository.
A little while later at 17:08:26 the vulnerability is officially confirmed by Madwifi and advisories had been prepared.
Looking downstream, the response times for an official fixes/advisories by distribution specific security teams were:
Gentoo: December 10
SUSE: Confirmed December 8, Fixed December 11
Ubuntu: January 9
There is certainly some room for improvement here with distribution specific fixes, but that also includes time spent testing the changes to the driver. To be fair to Microsoft (actually, I'm just being overly optimistic), they probably had a patch ready within 30 minutes of the initial vulnerability report as was the case with Madwifi. But instead of giving the customer the option of trying the "beta" patch so they can test it themselves, it is kept private. Days tick by at Microsoft HQ and nothing appears to happen. Eventually, a patch is released on the patch Tuesday of the next month (or the month after that). System administrators get no choice and no chance to test it themselves.
The headline should instead read something like Hackers Create Exploits Using Microsoft Published information. This IS what hackers do after all. They read documentation and manuals. They find out how things work with all the available information. They social engineer. Trying to pin this on Microsoft is childish.
It falls apart pretty much at the obscurity versus security part:
..).
;)
I've broken into houses. I'm neither proud nor ashamed (I was young, it's the least of the stupid things I did). Leaving your door open *would* increase the chances of you being broken into. Being broken into *would* increase the chances someone sees the money you've cleverly laid out in the basement.
Meanwhile, you would have been much safer having just posted directly on your front door that you had $20K and installing your (*cough* firewall) security system and done a few basic checks (front door locked? firewall on?
At least enough to deter most of your garden variety criminals (heh, kind of like script kiddies?).
Anyway, I hear they new Volkswagon promo is just under 20K? This is so much sweeter then the bus!
Quack, quack.
You realise RPC is, in fact, a UNIX feature? That it's there on your Linux/Sun/BSD/OSX box? That like anything running on a known port it's easily blockable at the firewall? Or via IPSEC if you don't run a firewall? And that the Win2003 firewall will block it by default?
Well done; next time I develop code I'll make sure I name my services something like "Sooper secure, non-remote admin interface", because we wouldn't want to make the cracker's job easier with a name now would we?
Open source also reduces the risk of needing this kind of thing in the first place. And that is true regardless of whatever the current state of Linux vulnerabilities vs Windows vulnerabilities.
In closed source, for whatever reason, MS can't seem to release zero-day patches. That is, they discover the vulnerability, or someone reports it to them, and the patch still has to wait till Patch Tuesday. Only exception to this is if it becomes public in a big way, such as an exploit in the wild, and even then, you don't really know what they'll do.
So, once an exploit has been discovered, your suggestion is to distract the crackers until the fix itself is in the wild, and perhaps a good deal past that. (Remember, there are quite a few groups which simply grab the latest patches, figure out what they do, and go exploit everyone who hasn't patched themselves yet.)
In open source, we do generally keep ourselves up to date. Or at least, anyone who is technically-minded enough to be using Linux in the first place will be able to tell their distro to update. The package manager helps here, too, as everything is automatically updated, not just whatever happened to be included in Microsoft Update or bothered to write their own update system.
So, the only question becomes, how fast can it be fixed, not what you do afterwards. One argument is that "many eyes make all bugs shallow" or however that's said -- once a vulnerability is known, there will be tons of people looking for the solution. But it goes deeper than that.
You'd probably be discovering the vulnerability by looking at the source code, meaning that whoever discovers the vulnerability should be able to see a solution right away. Buffer overflows are a great example here: If you can see a buffer overflow in the code, you can almost certainly see the solution right away. Send in a tiny patch, and it's fixed before anyone had a chance to know there was something wrong.
And it goes farther than that, too: What about that person who initially discovers the bug? Suppose it's me, and suppose that I also know how to fix it, given the source. What do I do with it?
Well, with Windows, I can tell Microsoft about it, and it may be fixed, someday. Or I can try to fix it myself -- not easy without source code, perhaps entirely beyond my abilities. And if I do fix it myself, what's my incentive to release it to the world? I don't particularly like Microsoft anyway, but why am I doing their work for them?
At this point, it would make much more sense to me to simply exploit it. Start my own botnet, get rich off of it, etc.
Now, suppose it's a problem with Linux. I can report it, but the instant I do, my report is fairly public -- this means they cannot just sit on it and hope the problem goes away. It also means that all kinds of other people are now in the same situation I am -- we know about the problem, and we have the source, so we may be able to fix it.
Or, I could sit on it till I have a patch. This is something that's really impossible to do with closed source, unless you happen to work at Microsoft (or whichever company has said source). In this case, I am the only person who knows about the vulnerability until there's already a patch available.
It seems to me that, unless I'm already a "black hat", I'm much less likely to become one if I can actually do something about a security flaw other than exploit it. After all, don't I want my own systems to be secure, at least?
What if it takes me some time to come up with a fix? What about backwards compatibility? If this is even close to being an issue, I do have one fairly large advantage here -- most software on Linux is already open source. So even if I break a huge number of programs, I can fix them again. For example: Microsoft cannot release a patch that would break Photoshop (for example; I know that's a stupid one), or if they do, they look like assholes. They would h
Don't thank God, thank a doctor!
C's time has passed! the IT industry can not afford it any more economically as well as politically. Even the slightest mistake can cost millions of dollars.
And before someone says it's all about the programmers and not the language, I would say I agree: it takes a God programmer to produce a flawless C program. The God programmer category has few members around the world, and most of them are not in Microsoft (hint: they are Linux / open source guys).
So it's time to stop using this horrific programming language called 'C'. It worked so far, but its flaws are very serious...time to move on!
You are confused, the phrase "security by obscurity" has a specific meaning in this context.
The secrecy of the password is, actually, the only secrecy not connected with it.
Good idea, if it wasn't for the fact that the legitimate uses for all these things far outweigh the trouble they cause.
I have excellent Karma and I am not afraid to Troll it.
Microsoft makes their name for producing quality code to begin with, right?
I'll peg them to try introducing chaff/fake exploits... and *missing*, at which point they get OWNED for real.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine