×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

MS Giving Exploit Writers Clues To Flaws

kdawson posted about 7 years ago | from the first-word-sounds-like dept.

Security 63

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

63 comments

I can see open vs closed source (5, Insightful)

Skreech (131543) | about 7 years ago | (#18761361)

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.

Re:I can see open vs closed source (2, Interesting)

Anonymous Coward | about 7 years ago | (#18761439)

>>But this is a case where a half-and-half approach is probably the worst of all.

Of course, going halfway on either ideology, closed or open source sets you up for trouble. Which is why it is a bad idea for Microsoft to release any details about their patches at all. Yes, I said it. If they are going to try and make a blackbox OS, they shouldn't do it half way.

Re:I can see open vs closed source (1)

renegadesx (977007) | about 7 years ago | (#18763447)

This is pretty ironic. Problem is if some security company finds exploits within Windows, I think they know if they want to do something about it, announce it to the public first, microsoft second

Re:I can see open vs closed source (5, Funny)

kestasjk (933987) | about 7 years ago | (#18763805)

Damn Microsoft! We need to know what patches are being applied so we know what may fail. We need full disclosure!

Damn Microsoft! Their full disclosure is allowing hackers to write exploits; don't tell the hackers how to hack my system!

Damn Microsoft! They're kinda going half way in a vain attempt to stop people flaming, as if I'm going to stop doing that! Stick with one or the other, we'll flame you whatever you do anyway.

The question is which half. (0)

Anonymous Coward | about 7 years ago | (#18766597)

Seems the problem is *which* half they give out first.

Seems the right flow of information is:
      1. First - disclose what application/service/server
            has a flaw - so customers who really care can
            disable the service and/or take the machines offline.
      2. Publish a workaround.
      3. Publish a fix and disclose exactly what went wrong and why.

I'd rather have half-and-half (1, Interesting)

Anonymous Coward | about 7 years ago | (#18761447)

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...)

Re:I can see open vs closed source (1)

physicsboy500 (645835) | about 7 years ago | (#18761537)

However, if microsoft were to go open source in their current situation there would be many people who would want to sabotage the project who are computer savvy enough to do good for the project in the first place. Microsoft has a large dominance and as can be seen by this patch release it is met with quite a bit of resistance.

Chaffing (4, Interesting)

goombah99 (560566) | about 7 years ago | (#18761661)

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.

Re:Chaffing (5, Insightful)

fm6 (162816) | about 7 years ago | (#18761813)

Microsoft should pre-publish a whole bunch of tasty looking security advisories that are 100% fake every time they publish one that is real.
If they had the expertise to do that, they wouldn't have so many security holes in the first place!

Re:Chaffing (2, Interesting)

MrShaggy (683273) | about 7 years ago | (#18761919)

So what you are saying is that some security by obscurity might be a good thing?

I personally think that there are uses for both. Its natural to have both in place.
One example is if I am the Coca Cola company, and I wan't to keep the formula a secret. I might go to great lengths in securing the room, in which you can read the formula. You owuld need to know the security, in order to access it in the first place.

If I had $20,000 in cash at my house, in the basement, and not tell anyone that it is there. If I accidentally leave the door open at night, I would assume that the chances of my house being robbed, are no different then any other night.

If I decide to protect the house with some motion lights, would I not also be served better with hidden cameras to take a picture of what-ever it was that triggered the light?

If I use infra-red sensors in a room, should I also use motion detection as well? THat way any attempts at getting past the first will immediately set off the second?

Aren't all these reasonable 'security by obscurity' examples that work ok?

Re:Chaffing (3, Insightful)

norton_I (64015) | about 7 years ago | (#18762083)

Aren't all these reasonable 'security by obscurity' examples that work ok?


Only one of them, the $20,000 in your basement. The reason you only do that for one night is that it isn't a good long-term security solution. Eventually, someone will find out that you have that much cash lying around and your chances of being robbed go way up.

Re:Chaffing (4, Interesting)

Daengbo (523424) | about 7 years ago | (#18762453)

The point about security through obscurity is that it shouldn't be used alone as the only source of protection. Many people change their SSH config off the default port to reduce automated attacks, but they don't leave it there in the most open configuration -- they disable root logins and sometimes require key-based logins instead of password-based ones.

Having an element or elements in your security setup which are irregular is a good part of a complete security picture, but don't for a moment assume that these will even slow down someone who knows what to do and is determined to get into your network. Only real security measures will do that. If you leave an unsecured FTP server on port 12056 facing the internet, someone will eventually find it and exploit it. If you leave phpmyadmin with no root password hidden in your website somewhere with no outside links, they still might find it, and then you are toast. Obscurity just stops most script kiddies. That's not bad, though, is it?

*COhg* No? (1)

msimm (580077) | about 7 years ago | (#18763661)

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! ;)

Re:Chaffing (1)

Hal_Porter (817932) | about 7 years ago | (#18763977)

I personally think that there are uses for both. Its natural to have both in place.
One example is if I am the Coca Cola company, and I wan't to keep the formula a secret. I might go to great lengths in securing the room, in which you can read the formula. You owuld need to know the security, in order to access it in the first place.


No, no, NO!

The Coca Cola should open source the formula and abandon any trademarks so that The Community can check the formula for health risks and contribute improvements, and make mashups of the trademark legally. Of course this will mean that a load of other companies can sell perfect unimproved copies of Coke cheaper since they don't need to amortize any marketing and development costs, but Coke can get out of the bottle selling business and still survive by providing paid support.

Coke's business model needs to move into the 21st Century. Have you read Cory Doctorow's essay on open source beverages?

Re:Chaffing (1)

Ajehals (947354) | about 7 years ago | (#18766011)

Since when does open sourcing anything give people the right to do anything other than look at the code (recipe in this case)? Duplicating / distributing / creating derivatives of something that is open source is still a copyright violation unless you have a license that says otherwise...

Re:Chaffing (1)

Hal_Porter (817932) | about 7 years ago | (#18766695)

Since when does open sourcing anything give people the right to do anything other than look at the code (recipe in this case)? Duplicating / distributing / creating derivatives of something that is open source is still a copyright violation unless you have a license that says otherwise...

That's not true - the point of open source is that users have the right to change the code and distribute changed versions. The license determines whether you need to release your source code changes, but both GPL and BSD allow you to distribute binaries to whoever you want.

If the Coke formula was under the soda equivalent of the GPL, you still be allowed to sell bottles of soda, equivalent to distributing the binaries so long as you wrote the recipe on the side, equivalent to distributing the source code. Or at least you'd need to make the recipe available if people asked for it.

If it was under the soda equivalent of a BSD license, you could distribute the bottles containing a modified soda without distributing the recipe, even if you modified it.

Re:Chaffing (1)

Ajehals (947354) | about 7 years ago | (#18768153)

There is a difference between making source code available and releasing the same code under a permissive license. Just because the GPL, BSD and the various common licenses are the most visible does not mean that that is the only way to release code.

A situation where a piece of software is open source, but does not come with any rights to distribute and/or modify code would be one where a company or government want to carry out a code review usually (but not exclusively) on the grounds of security, or compliance. Just because you have no experience of the source code being available for a piece of software that does not come with a permissive license, does not mean that it is not something that happens regularity.

To take it one step further, I have worked with organisations where they have had access to source code under a restrictive license. The license in that instance did allow for code modification (the licensee had a large number of developers, and the application was core to the business). Changes could be made however they could certainly not be distributed (the software was licensed per server and per seat, at well over £3000 per seat), and if changes were made, the support contracts were invalidated. If you wanted a change to be supported, you needed to submit the alteration to the company providing the software with a transfer of copyright (i.e. you no longer owned copyright to your own changes). If you were lucky those changes would be accepted and support continued.

The above does constitute open source code as the source is open and available, it does not however fit in with the principals of the FLOSS movement. It is still a hell of a lot better than buying completely closed software where you have no options.

Re:Chaffing (1)

Sajarak (556353) | about 7 years ago | (#18764237)

So what you are saying is that some security by obscurity might be a good thing?
Most security systems use obscurity to some degree. If restricting access by passwords isn't security by obscurity, then what is it?

Re:Chaffing (1)

marcosdumay (620877) | about 7 years ago | (#18765821)

"Aren't all these reasonable 'security by obscurity' examples that work ok?"

Only for people that doesn't understad what is 'security by obscurity'. Most security systems depend on something being secret. Security by obscurity is when you tell that secret to the enemy, but in a hard to read way.

And it only works if what they can gain from you is worth less than the cost of deciphering the secret. That is, almost never.

Re:Chaffing (4, Insightful)

AndrewM1 (648443) | about 7 years ago | (#18761977)

The problem with this is the bad press MS would get from announcing 11 exploits for every one they discovered. Those "outside the know" would think MS insecurity had gone up by 11x. MS already has major press issues about their many security exploits, they don't need 11 times that.

Also, introducing fake honey pots in the code would cause problems. If they announced it and fixed each one, the honey pots would be useless. If they announced it but didn't fix it, they'd look like they didn't care/or it would make it obvious it was a honey pot. If they didn't announce it or fix it, then invariably some security researcher would find it (it has to be discoverable to become a honey pot) and blast MS for the security vulnerability.

Re:Chaffing (1)

goombah99 (560566) | about 7 years ago | (#18762091)

I don't think people would care any more if it was 11x higher. Besides which they could even announce they are doing it. That would shut down those pesky security researchers who always claim that some bug might lead to a remote code exploit without actually working outhow it might. They'd hold their fire because then they would look stupid not MS when they find out it was a honeypot.

As I mentioned in my first post, each time they send out a patch they fix all the honeypots so no one can tell and then pre-load another set that will lay dormant until they need to announce another bug. Then they announce those salted ones too.

Re:Chaffing (0)

Anonymous Coward | about 7 years ago | (#18762197)

(posting as AC because I've modereated)

People would care if the reported bug count was 11x higher, because Vista is being touted as the most secure OS yet. How could it be considered "secure" if it has 11x the patches of (say) XP?

Your idea is interesting, but consider for a moment that MS would have to be creating 10 "honeypot" flaws per patch per month - flaws that won't impact upon Windows but still be there. It can take a few months to ensure a patch doesn't impact on the rest of Windows - each of these traps would require at least the same level of verification and testing.

Re:Chaffing (1)

goombah99 (560566) | about 7 years ago | (#18762479)

If MS announces it it using honeypots then no third party can even keep statsitics on how many flaws it has. it will make any published stats meaningless and laughable. MS can even deny any claimed bug, saying it might have been a honeypot and that it's policy is never to comment on the true identity of bugs it has patched.

Really it's perfect because it frustrates those that want to somehow prove MS is less secure by counting bug rates.

(those numbers are kinda meaninngless as there is so little normalization over what counts as a bug in open versus closed source communities. Firefox for example has a higher bug rate than IE by some counts, but that's because firefox's bug tracker tends to make it look like there are more bugs than their really are, and distorts their criticallity.

Re:Chaffing Poorly? (1)

TaoPhoenix (980487) | about 7 years ago | (#18766513)

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.

Re:Chaffing (1)

angulion (132742) | about 7 years ago | (#18773753)

This in addition to honeypots meaning more code, which usually translates to more potential bugs and security vulnerabilities.

Wouldn't that be ironical - a honeypot leading to a real exploit?

Re:Chaffing (1)

mcpkaaos (449561) | about 7 years ago | (#18762065)

Well because you could only get away with this in closed source. Open source would make this a give-away.

Unfortunately, so would a decent debugger. It's a pretty cool idea, though. :)

Mod parent up (0)

Anonymous Coward | about 7 years ago | (#18762593)

highly clever.

Re:Chaffing (1)

cp.tar (871488) | about 7 years ago | (#18763257)

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.

OTOH, maybe the cracker will find his time had not gone to waste.

Just because MS think a piece of their code is good, it doesn't mean it is so. After all, they do need bugfixes and service packs and whatnot.

Putting up honeypots may just be giving the crackers some ideas...

"Malfromed word" ... classic (0)

Anonymous Coward | about 7 years ago | (#18764399)

You weren't trying to exploit my IE7 browser based on that bogus pre-patch advisory, now, were ye? Were ye?

Not so relevant to open source (1)

SanityInAnarchy (655584) | about 7 years ago | (#18764529)

Open source would make this a give-away.

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 have to call up Adobe and work with them, possibly a long beaurocratic process, scheduling the moment when both fixes will be available, or figuring out how to fix it in such a way that Photoshop doesn't break, or at least, that the photoshop fix is included in the Windows Update.

Whereas if I release an update which (somehow) breaks the Gimp, I can simply go fix the Gimp. Chances are, if I understand the original vulnerability enough to fix it, I probably understand the backwards compatibility issues enough to fix those. And probably in less than a day. Once I've released both of those, distros can distribute the fixes via package management -- which means that both patches are applied simultaneously, or not at all if a user held them back (dependencies).

Now, looking again at your scheme -- you're right, it doesn't work with open source, and that kind of makes me glad, because in this scheme, we're trusting Microsoft that their "honeypots" are actually harmless, and that the real exploit is actually being fixed. In open source, I don't really have to trust anyone except myself, and in any case, enough people read the code that it would be much more difficult for someone to deliberately introduce a bug.

I don't think either of us has actually made a statement about which is more secure overall, but I do hope I've made my point here: Open source has a fundamentally different approach to security. I believe it's more effective, but the point I'm making is simply that it is so fundamentally different that certain concepts (like "Patch Tuesday") simply don't apply. It's not that open is better than security through obscurity, but rather that you can't really compare the open process to security through obscurity.

When in doubt provide more information (2, Interesting)

Anonymous Coward | about 7 years ago | (#18761385)

Umm, do these people really think that hackers can't reverse engineer a patch and see what it's doing??

IT admins will be the most affected .. 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.

Hackers that RTFM .. now that's funny.

Re:When in doubt provide more information (4, Insightful)

Anonymous Coward | about 7 years ago | (#18761629)

Hackers that RTFM .. now that's funny.
Actually, hackers DO RTFM [catb.org] .

They also know How To Ask Questions The Smart Way [catb.org] .

Crackers have the upper hand on system administrators, because the focus is very narrow. System administrators have to RTFM and stay up-to-date on everything from why Alice can't print (because her network cable is unplugged) through to debugging the cause of a fatal exception/crash in a plugin they've written for a HTTP daemon. System administrators are very overloaded with work whereas crackers can take it much easier.

Re:When in doubt provide more information (1)

Architect_sasyr (938685) | about 7 years ago | (#18762155)

Of course the really good crackers are also sysadmin's as this gives them the best insight into how a system works and the ways the security is thought out... they probably also write really nice code for a software company or freelance.


Note: This is a generalisation of a select group. It will not cover every possibility.

Tick tock tick tock... (1, Interesting)

Anonymous Coward | about 7 years ago | (#18761397)

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?!

Re:Tick tock tick tock... (2, Insightful)

644bd346996 (1012333) | about 7 years ago | (#18761453)

Open source projects have to write security advisories, too. They just have the option of including the patch with the advisory.

Shoot from the hip fixing is not always right (5, Insightful)

EmbeddedJanitor (597831) | about 7 years ago | (#18761843)

In any reasonably complex hunk of software, the chance of being able to confidently fix a oneliner and release it immediately is pretty low. Most software needs verification/testing of some sorts before a change can be mainstreamed.

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.

Compare the facts: open source patching is FAST (4, Interesting)

Anonymous Coward | about 7 years ago | (#18762113)

Let us take a look at the recent topic of a Madwifi vulnerability affecting certain wifi users in Linux.

Julien Tinnes reported [immunitysec.com] it at 13:48:00 EST on December 7, 2006.

At 14:17:50 on the same day the patch [madwifi.org] was available in the main source code repository.

A little while later at 17:08:26 the vulnerability is officially confirmed [madwifi.org] 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 [gentoo.org]
SUSE: Confirmed December 8 [novell.com] , Fixed December 11 [novell.com]
Ubuntu: January 9 [ubuntu.com]

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.

Re:Tick tock tick tock... (1, Insightful)

Quantam (870027) | about 7 years ago | (#18762089)

Congratulations. You have just unwittingly illustrated the mindset that makes businesses wary of open-source software, and gives bite to Microsoft's FUD. Of course not all open source coders have such a knee-jerk mindset, but you are a member of an influential (in intimidation power, not number) minority.

Remember how XP was cracked? (2, Interesting)

UnknowingFool (672806) | about 7 years ago | (#18761403)

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.

Clear choice (3, Insightful)

The Bungi (221687) | about 7 years ago | (#18761425)

Microsoft should stop providing so much information in their advisories. Or better yet, stop issuing them altogether. Oh, wait. They used to do that, and that proved unpopular.

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.

Re:Clear choice (1)

ResidntGeek (772730) | about 7 years ago | (#18761487)

You hit the nail on the head with the Blaster comment; this discussion is moot. Wasn't it 3 or 4 days ago that we all read (the summary of) a story saying most botnets are built with two well-known worms? It might make sense for a few system administrators with enemies to worry about this 'sploit, but 99% of people have bigger things to worry about.

Re:Clear choice (0)

Anonymous Coward | about 7 years ago | (#18762803)

Or they could... WRITE BETTER SOFTWARE! Is that option just not even on the table any more? "Waah, writing software is HARD."

*steam comes out of ears*

Better than a zero day (1)

cachimaster (127194) | about 7 years ago | (#18761509)

If MS hides the vulnerability info, it's gonna leak anyway and now you gonna get owned and not even know it. If you publish early advisories, at least you got the chance to take some measures preventing the attacks.
Remember, a zero day is a *unpublished* vulnerability. You don't want hackers with zero days in their hands.

I think MS is exactly right to do this (0)

Anonymous Coward | about 7 years ago | (#18761553)

I mean come on /. this practice makes perfect sense.
I wish I could elaborate, but I am preparing to leave on a vacation, and must put a note on my door stating:
"Hi neighbor, I am going to be out of state, please feed my dog, you may enter through this unlocked door"

Fabulous (4, Insightful)

SeaFox (739806) | about 7 years ago | (#18761561)

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.

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."

Re:Fabulous (1)

Geheimagent (679949) | about 7 years ago | (#18764915)

"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."
This is like the infamous openssh bug that urged everybody to upgrade to version 2 without giving a reason, even though many weren't vulnerable.

Supply cs Demand? (0)

TheSkyIsPurple (901118) | about 7 years ago | (#18761611)

I wonder if this continues, if the price for exploits will go down, since they can more quickly get replicated, there may be more of an actual market.

There was already exploit code before the advisory (5, Informative)

Anonymous Coward | about 7 years ago | (#18761675)

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.

Re:There was already exploit code before the advis (3, Interesting)

Anonymous Coward | about 7 years ago | (#18762003)

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.

all your eggs in 1 basket (0, Flamebait)

Gothmolly (148874) | about 7 years ago | (#18762039)

Who would put their DNS server / user repository on the same box, and expose it to the Internet? Oh wait, thats EXACTLY what MS wants you to do... its easier, and the nice Wizard helps you through all those pesky details.

Re:all your eggs in 1 basket (0)

Anonymous Coward | about 7 years ago | (#18762449)

Actually no. If you follow their guidelines, all your DCs (AD, DNS, et al) are inside your firewall and they should have ipsec rules that only allow encrypted traffic.

Your PUBLIC DNS servers should only do DNS and you should have ipsec rule that lock down everything BUT DNS.

There's always a "0-day" (1, Insightful)

omgwtfroflbbqwasd (916042) | about 7 years ago | (#18762339)

It really doesn't matter how much information you disclose about the technical details or workarounds except in how long it will take to develop the exploit. Once an exploit writer knows there is a critical vuln in a particular area of the system, it's not that hard to narrow down the inputs required to exploit it. In particular, Metasploit makes this much easier [wikibooks.org] to do by being able to see what memory offsets are in EIP when the process segfaults.

The only real impact is how many people will be able to write their own 0-day, and how quickly. Personally, I'd rather see more exploit development, since it proves a risk rather than making it theoretical (and likely only exploitable by the 31337).

+1 troll to the headline (5, Insightful)

twifosp (532320) | about 7 years ago | (#18762817)

That headline is utter rubbish and sensationalist. Microsoft is not giving anyone clues to create exploits. The wording makes Microsoft sound intentionally malicious. While Microsoft is pretty god damn malicious, they aren't out there trying to help exploit writers.

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.

Re:+1 troll to the headline (1)

atamyrat (980611) | about 7 years ago | (#18764195)

+1 troll to headline? oh I thought it was -1.

Now does it mean that I can improve my karma by trolling? :-)

Here's an idea that Microsoft hasn't thought of: (-1, Troll)

Whuffo (1043790) | about 7 years ago | (#18763549)

They could save some patch-writing effort and a lot of PR headaches by simply taking a deep look at all of their "action at a distance" misfeatures with an eye to how they could be misused.

All of those things like ActiveX, remote administration, etc. Anything that allows someone else to execute code on your computer; how did they ever imagine this would be a good idea? How about leaving some of that vunerable code out of the shipping product?

Just look at the name of the vulnerable service in the current newsflash; RPC, aka Remote Procedure Call. How nice of Microsoft to make the cracker's job easier - all he has to do is poke in his exploit code via the typical buffer / stack overflow and use the friendly Microsoft-supplied interface to trigger it.

That reminds me - didn't they make a big fuss a while back about how they'd gone over all the code and eliminated all the unchecked buffers, etc. Clearly that didn't happen; makes one wonder if they're lying or stupid...

Re:Here's an idea that Microsoft hasn't thought of (4, Insightful)

blowdart (31458) | about 7 years ago | (#18763925)

You realise RPC [exct.net] 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?

GOOD POINTS AND YOUR MOD UP IS DEAD ON BLOWDART (0)

Anonymous Coward | about 7 years ago | (#18791893)

"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?" - by blowdart (31458) on Tuesday April 17, @02:47AM (#18763925)

Good points blowdart... here is one you can add to your arsenal, so to speak (correct me where needed if you feel it is necessary. I grow more by critique than by any other thing I get online imo).

Here goes, in regards to the quote of your words above: OR, via port filtering (present in NT based OS' as far back as I am aware of, working via ipnat.sys & ipfiltdrv.sys working with tcpip.sys iirc, & in this order:

1. After the IP packet has been formed, Tcpip.sys passes it to the firewall-hook driver, Ipnat.sys, for processing.

Windows Firewall checks whether the traffic is a specific type of Internet Control Message Protocol (ICMP) message that Windows Firewall is designed to block. If the ICMP message is blocked, Windows Firewall discards the packet.

Windows Firewall checks whether the traffic is Point-to-Point Tunneling Protocol (PPTP) tunnel maintenance traffic. If so, Windows Firewall analyzes the traffic to determine the Generic Routing Encapsulation (GRE) Call ID that identifies the specific PPTP tunnel so that incoming GRE-based traffic for the PPTP tunnel is allowed.

If needed, Windows Firewall adds a dynamic entry to the exceptions list so that the response traffic will be allowed.

After processing, Ipnat.sys passes the IP packet back to Tcpip.sys, which uses the IP forwarding component to determine the next-hop IP address and interface. For more information, see Understanding the IP Routing Table.

2. Tcpip.sys passes the packet to the filter-hook driver, Ipfltdrv.sys, for processing.

Based on the next-hop interface, Ipfltdrv.sys compares the packet to the configured outbound IP packet filters.

If the outbound IP packet filters do not allow the packet, Ipfltdrv.sys silently discards the packet. If the outbound IP packet filters allow the packet, Ipfltdrv.sys passes the packet back to Tcpip.sys.

3. Tcpip.sys passes the packet to Ipsec.sys for processing.

Based on the set of IPsec filters, Ipsec.sys determines whether the packet is permitted, blocked, or secured. If permitted, Ipsec.sys passes the packet back to Tcpip.sys without modification. If blocked, Ipsec.sys silently discards the packet. If secured, Ipsec.sys adds the appropriate IPsec protection to the packet before handing it back to Tcpip.sys.

Tcpip.sys then sends the packet over the next-hop interface to the next-hop IP address.

(In fact, specifics of mechanics and ordering for your reference in the future is here -> http://www.microsoft.com/technet/community/columns /cableguy/cg0605.mspx [microsoft.com] & that's where I learned the mechanics/specifics of it better than I had it down when I started using & learning about this stuff back in the NT 4.0 days).

In other words, for your reference? You can stall RPC stuff that way as well by ip filtering if necessary, and it works with your software AND hardware firewalls as well, and is often called "the poor man's firewall", since it is less flexible than security policies or software & hardware based firewalls out there today.

It is good for layered security when all is said & done & works FINE with today's software and hardware firewalls as well as ipsec stuff for the most part and like the other more commonly used methods for security you noted? Well, It just works and in combination with them all running concurrently for layered security online.

Still, what I am trying to say is this:

I found your post worth every point you have been modded up to by the staff here for, because you are absolutely correct afaik!

* Good job!

APK

Re:Here's an idea that Microsoft hasn't thought of (2, Insightful)

ThirdPrize (938147) | about 7 years ago | (#18765019)

Good idea, if it wasn't for the fact that the legitimate uses for all these things far outweigh the trouble they cause.

Yet another buffer overflow...time to stop using C (3, Insightful)

master_p (608214) | about 7 years ago | (#18764921)

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!

A Casual Understanding of How Microsoft Sees You (0, Troll)

LifesABeach (234436) | about 7 years ago | (#18767475)

It is melancolie that once a typical person learns a desk top manager, that that person will stay with that desk top manager; Even when it means giving up big bucks [neowin.net] , as opposed to just downloading a copy of Ubuntu 7.04 [ubuntu.com] - For Free! Microsoft knows this, cold. When it comes to those who would exploit users sloth for purchasing a known product riddled with flaws, it only takes a enterprising few to ruin every microsoft user's day; Globally. One should notice that Microsoft's "Software Agreement" says you can not sue them for their negligence, but not the other way around [com.com] . Mircrosoft may be many things, but foolish is not on that list.

I'd like to thank Jim Allchin... (0)

Anonymous Coward | about 7 years ago | (#18775717)

...for telling me there was an exploitable overflow in MSMQ.

http://www.google.co.uk/search?q=allchin+message+q ueueing&start=0&ie=utf-8&oe=utf-8&client=firefox-a &rls=org.mozilla:en-US:official [google.co.uk]

    He didn't say exactly what or where; he didn't need to. I'd been thinking of looking at it anyway because it looked interesting, and because I'd been studying MSRPC, and because my local bookstore had had a book on MQ and MSMQ on sale cheap for a fiver, and I'd bought it and taken a look at the kinds of APIs and operations it involved.

    It took *30 minutes* to find. It was pretty much the first thing anyone would have thought of trying if they'd chosen to look at that protocol. It didn't make any difference whether he'd mentioned it or not, because I still would have found it that quickly the minute I'd looked.

    So frankly, there's nothing they (MS) could even say at all, no matter how small, that wouldn't give a clue to someone who's looking; and likewise, someone who's looking doesn't need any clue at all, no matter how big.

    Therefore I feel that there are only benefits in being open with this information, for those who need to know what is dangerous so that they can take steps to protect themselves. I don't believe hushing it up in any way impairs the ability of people to discover and exploit a hole.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...