Security Community Reacts to Microsoft Announcement

A number of readers have collected stories concerning the change of focus by Bill Gates to security. Bruce Schneier and Adam Shostack have written a piece, while Crag Mundie of MSFT has also chimed in, along with some commentary from ZD folks. SecurityFocus has other words, as does InfoWarrior.

Comments

Speedreader's summary of all 6 articles

[Score0, Overrated]

It will be good if they succeed; we hope they try as hard as their PR says they will.

Have a nice day.

Cringely, too

[what_the_heck]

Cringley has a good piece up on this as well.

the register

[horster]

register has been following this pretty closely.
they have a good editorial on what it would cost to ms to implement this as well (like dropping .net until the security implications are thought through)

here is the link -
http://www.theregister.co.uk/content/4/23791.htm l

Bush is for sale

[Anonymous Coward]

Face it, W will shake Bill down until he writes a big fat check and then M$ will get a pass. Just look at how W and his VP delt with Enron and other big energy. Money Talks and then MicroSoft Walks. THat's just the kind of boy W is.

SOAP and the MSFT way

[BlackStar]

There is a side thread in progress that touches on how SOAP is addressed in the article. I think SOAP deserves a lot more attention, especially as it affects MSFT, and the new .NET initiative.

SOAP is designed to use HTTP/HTTPS as the most common implementation of transport and protocol underneath. Schnier and Shostack touch on how poor a decision this is. I think this goes a lot further than many developers and companies are realizing.

You just removed your firewall.

The idea of SOAP is to allow IT services to be exposed as remotely addressable and usable procedures. Essentially with every web service or SOAP receiver, you have written a brand new server that parses XML protocol messages to decide on action. Thus every web service you create may have overrun, DoS and other exploits inherent in it, in your code, as you are executing paths based on a message from the outside. Just like a web server, ftp server or any other available server.

So now, everyone has to become better at security, to the point that the web services are safe. Ideally they should all run within a sandbox environment with restricted permissions, but considering SOAP authentication is based on HTTP authentication, the models may or may not match up properly.

Most importantly is that the SOAP specification team, including MSFT and the .NET portions pertaining to web services have basically increased the difficulty of every network administrator's job by stuffing all this over port 80.

Now if there is a vulnerability in a web service, the network admin has to take out port 80, probably taking down the web service, the web server, and who knows what else that's been tunnelled through there. They can't simply block a set port. UDDI could have advertised a port for the service as well, and stateful inspection could be implemented at some level on each service port to increase security and leverage off of the firewalls. Instead, a rat's nest of information is getting funnelled through http/https. The firewalls aren't designed for this, and the inspection task is only going to get more difficult as SOAP grows in popularity.

MSFT is always looking at first to market, and I can almost assure you that for that reason, SOAP was designed around port 80 and into the web server engines. I can also say with a fair bit of confidence that the first time MSFT gets beat to market due to a security review, that the security priority is going to get thrown right out the window of the executive windows at Microsoft if it causes the stock to slip.

Re:Schnier co-writes a bad column!

[Cally]

>The point is that running SOAP over SMTP or NNTP
>does not make a lot of sense

A free clue:
$ cat /etc/services

No one is (seriously) suggesting running SOAP over FTP or NNTP. The point is that one of the fundamental features of the IP suite is that unique services should run over unique ports. This has a wide variety of benefits, one of which is that you can SHUT IT DOWN AT THE FIREWALL (or border router or whatever) when someone blurts their new exploit all over Bugtraq without bothering to inform the vendor. As it stands, when this scenario comes to pass (or the first .NET worm breaks out, or whatever) the network admin will have to make a choice between killing all web traffic as well as the (completely unrelated) SOAP services ,or leaving them open and taking a chanceon not getting hit. [Or running an application-layer proxy, with the concomittant issues of security, resources, latency etc etc.) And when the MD or CEO calls up asking why he can't get to CNN.com, what's he going to say? Running SOAP over port 80 is a really dumb idea.

Incidentally when I said this here, a few months back, I got the most severe flaming I've ever had on Slashdot... nice to see that everyone's nodding sagely and saying "yes, of course, how true" now that Bruce Schneier says so, too. Apologies accepted =)

> FTP is actually built on Telnet and there are good
> reasons not to use SSL with Telnet which is why SSH
> is no longer based on SSL.

I have no idea what are you talking about here. ftp is "built on telnet"?

And FYI, SSH - OpenSSH at any rate - still had OpenSSL as a dependency
last time I compiled it (a couple of months back.)