Scan through it for a while and you get a bit of an idea of the direction he thinks in, publicly at least.
For example:
IBM is in a real pickle. Red Hat's dominance leaves IBM almost entirely dependent upon SuSe/Novell. Whoever owns Novell controls the OS on which IBM's future depends. Now that's an interesting thought, isn't it?
But if IBM preemptively acquires Novell/SuSe, the world changes: linux enters the product portfolio of a patent litigator not known for being a social-movement company. But where else will IBM go? With it's current market cap, Red Hat seems unacquirable - but absent action, IBM's core customers will be eroded by Red Hat's leverage. And Sun's ability to leverage our open Solaris platform (on industry standard AMD, Intel or SPARC), or Java Enterprise System, even on IBM's hardware, gives us a significant - and sustainable - competitive advantage. With the demise of AIX, IBM is once again vulnerable.
Me, I'd keep a close eye on the Novell/SuSe conversation. If IBM acquires them, the community outrage and customer disaffection is going to be epic... but where else does IBM go?
Or:
And proving our commitment to building Solaris as the cross platform standard, we're now compensating Sun's hardware salesforce for selling Solaris on non-Sun hardware. So if a sales rep sells Solaris on Dell or IBM, or even HP (Xeon or Nocona), we pay them as if they sold the hardware. This is a huge culture change, obviously. It also focuses everyone on keeping customers happy - and driving hardware choice. (And Fedora upgrades.)
I'm not sure we could make the point more clearly that we're committed to making Solaris the volume leader on all systems - and building the most price performant systems a customer can find. How confident are we Solaris customers will choose our new SPARC and Opteron systems? We're comp'ing our reps the same, no matter which systems the customer buys. We're putting money where our mouths are. Want proof? Got a farm of legacy Xeon systems, supplied by someone other than Sun? Talk to your rep to license Solaris - and let me know how it goes.
Sun definitely seems to think they have a strong competitor to Linux with Solaris 10, especially with adding support for running Linux applications. Their pricing for Solaris x86 is ballpark with suse or red hat enterprise.
Sun realizes that Linux is making certain layers of the stack a commodity, and is fighting strongly both on the front of bringing Solaris into the market while providing some added value (what a change from when they were killing Solaris x86 just a short while ago...) and moving up the stack (java desktop, application servers, etc.) while at the same time trying to expand their offerings of commodity servers that can run any platform... and using that as an entry point to get Solaris in the door.
I mean, "duh" Sun competes with Red Hat, and makes a big deal about being able to be a vendor that has a full hardware and software stack of their own. I don't, however, see any signs that Sun is betting the farm on Solaris.
So... the first course teaches all of "software development life cycle, OO Concepts, introductory Object Role Modeling (ORM), Entity Relationship Diagrams (ERD), HTML, ASP.NET, ADO.NET, Visual Studio Enterprise Architect, C#, Structured Query Language (SQL), Microsoft SQL Server, and XML basics.". That is quite the... course.
Nothing new here, just another technical institute trying to sell their courses as something they aren't... I have no idea if it is a good program or not, but it isn't a CS degree.
This isn't just about a license for the Apache HTTP server. In fact, it isn't even just about ASF projects either, since it offers independent developers a new choice of license to easily release their code under.
what genius came up with the idea for light grey text on a white background!?!
Maybe it was barely readable on their mac with its default gamma settings or on a CRT, but on many or most LCDs on anything other than a mac it is almost completely unreadable.
You would think that is one of the EASY things to get right!
First, they ran it on 2.1-dev code as of 1/31/03, which is some time ago now.
They found 31 supposed "defects".
29 were null pointer dereferencing, 2 were uninitialized variable use. You got it, they don't do any analysis of defects much more complex than a good compiler may do.
After looking through a handful of their supposed errors, many of them are pure crap because their tool isn't smart enough to figure out that a variable really can't be null.
Their analysis also doesn't consider the fact that subroutines may have APIs that are guaranteed to return certain things, so not checking for null is perfectly legitimate.
Bottom line is this is a company with a fairly primitive product trying to get advertising; some fraction of the alleged defects are actually bugs, most most of them are of a very very minor nature and many of them don't really exist at all.
The claim that "no hosts should be allowed to send traffic to this port" is based on a lack of understanding about how IP works.
If my machine, for example, does a DNS query to port 53 on your DNS server, it can use a more or less randomly assigned source port. If that source port happens to be 1434, then to respond to my query the DNS server will have to send a packet to port 1434.
Most systems don't use such low numbered ports for anonymous (aka. ephemeral) ports, but they can and some do. Filtering all traffic to udp port 1434 (or any particular udp or tcp port) is _NOT_ a good practice in general without knowing what is running on the hosts in question. However, it is unfortunately necessary at this time on many networks to deal with this worm.
A growing number of sites deny access to users under 13, or require special parent's permission to access them. This is a result of the COPPA legislation. So yes, you are right, you have more legal privacy protection then.
...but you are missing the detail that you won't be able to access a small, but well used, portion of the net, or you will have very restricted access to sites. Changing your birthdate later when you run into this isn't always possible.
In fact, Microsoft was actively contacting reporters to let them know about the issue and try to put their spin on it even before I released my exploit.
A number of Microsoft employees also leaked it to their friends after I reported it to Microsoft, and it started spreading from there.
And even Microsoft's lawyers were in on the gig of making sure everyone knew about it.
But seriously... Microsoft has been, and almost always is, very good about timely responses to security reports. Their problem is in dealing with them without having to be told by some Joe User that they have problems.
it isn't just about hotmail and passport wallet
on
Passport's Pocket Picked
·
· Score: 5, Interesting
While I make this point in my paper, I just wanted to make sure people understood:
The real risk here isn't to hotmail or passport wallet (passport wallet isn't really an integral part of passport, just another service using it for authentication). It is to all things using passport. That isn't so much right now. But if Microsoft has their way, it will be. The sample exploit used Hotmail and Passport Wallet simply because they are commonly used services.
I would also like to note that Microsoft has been quite forthcoming with details and admitting the problems and fixing them. They are very good at being reactive. We will have to see how well this works going forward.
This isn't an April Fool's joke!
on
TCP/IP Over HTTP
·
· Score: 2
Well, ok, the particular protocol is. But the reality is there are a staggering number of (slightly) more specialized protocols designed to do exactly this.
Very interesting how "well used/abused" (depending on your perspective) HTTP is, and how stupid many firewalling policies are.
Wake up and smell the cookies. Although not entirely technically accurate or complete (because you could never get such a thing past a typical reporter), he is bang on.
Yes, they have a big bug. However, name a site, any site, that makes significant use of cookies and I can almost guaranatee you that you can steal cookies for that site using "cross site scripting". And that isn't going away.
It is _CRITICAL_ that sites properly manage their use of cookies to minimize the problems from people stealing cookies in whatever manner. That is the message that needs to be coming out here because that is the _ONLY_ thing that can reduce the risk for users in the long term.
However, be sure to note that the only reason this stops this particular exploit is because the page is coded to check for the browser. If it wasn't, then simply sending a different User-Agent would be no protection at all.
You don't need a bug in IE to do this. The 404 error page on www.blogger.com is vulnerable (the default 404 page on IIS5 is, or was, vulnerable), so any browser with javascript (or other scripting languages, or even some without) is vulnerable through "cross site scripting" exploits.
So, as I said before, sure this bug in IE is a pain but it isn't all that significant compared to the known issues out there...
Oh yea. Your page boils down to "letes invent a new very weak encryption scheme". Then you explain why encrypting the username and password don't do much good (ie. if they are what authenticates the user, then any user who gets that info is authenticated as the user) while ignoring the little point that your magic scheme suffers from the same problem!
It is pretty obvious that you can and should do something other than just sticking the password in a cookie, and most sites do. Then many sites, such as Amazon, still require you to enter your password before doing "important" things.
What are you talking about? "javascript in general can cause a security leak"? Huh? You don't make any sense. This has nothing to do with "javascript in general" and is 100% an IE implementation bug.
The only bug here is that you can make IE make requests with a Host: header that doesn't really resolve to the machine in question. So sure, there is some risk of cookies being exposed to the default vhost on a server when they should only be sent to a particular vhost, but that is a comparitively tiny risk.
But Navigator has a far bigger problem (allowing you to embed CRs and LFs within HTTP requests) that lets you do this or more. I posted about this some time ago on bugtraq. Unfortunately, Netscape doesn't give a damn. If you are looking at response to security issues, no matter how bad MS is, Netscape is 100 times worse. Combine a company with no direction and not much in the way of a production plan with most clueful employees having bailed out, with the remaining ones just not giving a damn... and that is what you get.
Sure, maybe it will work on some sites. But that is due to other holes that they have. Try it on amazon.com. You won't get far, since they require you enter your password to do that.
Umh... if you are running arbitrary javascript that can display the cookie, then it doesn't take any genius to figure out how to send it somewhere! Like... load a URL on the attacker's server (or a free throwaway account) containing the value of the cookie.
I have no idea what they did. I know that _I_ reported a very similar issue (possibly due to the same root problem) with the exact same consequences to Microsoft two months ago and they have not yet released a fix.
Sure, I got a quick response saying they were looking into it. Sure, they said they had developed a patch. But releasing it? Well... that didn't quite happen. It is true that I did not pressure them on it since I was busy with more important things, but I shouldn't have to.
Take a look at amazon's site. You can not enable one click ordering without knowing your password. You also can't do most account related things without knowing your password. This is done by Amazon on purpose.
Now, they _did_ have some pretty gaping bugs in this area a few months ago that let you bypass this. I pestered them enough and they eventually fixed them though.
Also note that one click ordering really isn't all that dangerous. It is more of an inconvenience. So what is the worst that can happen? You can get some item sent to you that you have the hassle of returning. You can't send it to a different address. You can't obtain the credit card info. etc.
First, ignore all the silly ranting about not being encrypted, etc. That has nothing to do with the issue. You can send cookies over SSL connections. You can set cookies that will only be sent over a SSL connection. etc. This type of cookie stealing problem is far easier to exploit than having to compromise the network over which traffic is flowing. That is a completely different attack that allows you to do a whole lot more than just steal cookies.
This particular vulnerability isn't actually all that "serious" in terms of new exposure. Lets look at the examples given on the page describing the exploit. hotmail, yahoo mail, amazon.com, etc... cookies for all those sites, and probably for every other site listed, are stealable anyway due to the so-called "cross site scripting" issue.
I have spent a lot of time with these issues and related ones over the past few months. By their very nature, cookies are not treated as confidential by the browser and are far too accessible. The only way to get rid of the problems that using cookies for authentication or private information have is to replace them with a mechanism that is designed from the ground up to protect that information.
Unfortunately, from the perspective of a web site creator, there are very very limited alternatives. HTTP basic authentication has its own problems, using SSL client side certificates has its own problems, MD5 digest auth has its own probems, etc. There is no current method that avoids all, or even most of, the problems. All you can do is manage your risk.
Some day I plan to write a document describing the various risks associated with authentication schemes and what can be done to minimize them, but that takes time...
I reported a similar bug to Microsoft on March 19th. My particular example was a URL in the form "http://10.0.0.1%20.msn.com/foo.html" which causes IE to load content from 10.0.0.1 but the Javascript code thinks it is.msn.com; this is a symptom of either the same problem or a very similar one.
However, they took their time to deal with it. I did not pressure them on it since I had more important things to worry about.
Slashdot Mirror
NCSA.
http://www.apache.org/history/timeline.html
The Apache HTTP server was an evolution, not a revolution.
Not that it is really relevant, but...
itunes.com was owned by "Esprit Engineering Corp." until around 2003-10-13, at which time it became owned by Apple.
Whois history courtesy of http://whois.sc/
Scan through it for a while and you get a bit of an idea of the direction he thinks in, publicly at least.
For example:
Or:
Sun definitely seems to think they have a strong competitor to Linux with Solaris 10, especially with adding support for running Linux applications. Their pricing for Solaris x86 is ballpark with suse or red hat enterprise.
Sun realizes that Linux is making certain layers of the stack a commodity, and is fighting strongly both on the front of bringing Solaris into the market while providing some added value (what a change from when they were killing Solaris x86 just a short while ago...) and moving up the stack (java desktop, application servers, etc.) while at the same time trying to expand their offerings of commodity servers that can run any platform... and using that as an entry point to get Solaris in the door.
I mean, "duh" Sun competes with Red Hat, and makes a big deal about being able to be a vendor that has a full hardware and software stack of their own. I don't, however, see any signs that Sun is betting the farm on Solaris.
How is this a Computer Science curriculum?
... the first course teaches all of "software development life cycle, OO Concepts, introductory Object Role Modeling (ORM), Entity Relationship Diagrams (ERD), HTML, ASP.NET, ADO.NET, Visual Studio Enterprise Architect, C#, Structured Query Language (SQL), Microsoft SQL Server, and XML basics.". That is quite the ... course.
Course Descriptions
So
Nothing new here, just another technical institute trying to sell their courses as something they aren't... I have no idea if it is a good program or not, but it isn't a CS degree.
Have you, erm, looked at the Apache Software Foundation project list lately?
This isn't just about a license for the Apache HTTP server. In fact, it isn't even just about ASF projects either, since it offers independent developers a new choice of license to easily release their code under.
what genius came up with the idea for light grey text on a white background!?!
Maybe it was barely readable on their mac with its default gamma settings or on a CRT, but on many or most LCDs on anything other than a mac it is almost completely unreadable.
You would think that is one of the EASY things to get right!
First, they ran it on 2.1-dev code as of 1/31/03, which is some time ago now.
They found 31 supposed "defects".
29 were null pointer dereferencing, 2 were uninitialized variable use. You got it, they don't do any analysis of defects much more complex than a good compiler may do.
After looking through a handful of their supposed errors, many of them are pure crap because their tool isn't smart enough to figure out that a variable really can't be null.
Their analysis also doesn't consider the fact that subroutines may have APIs that are guaranteed to return certain things, so not checking for null is perfectly legitimate.
Bottom line is this is a company with a fairly primitive product trying to get advertising; some fraction of the alleged defects are actually bugs, most most of them are of a very very minor nature and many of them don't really exist at all.
The claim that "no hosts should be allowed to send traffic to this port" is based on a lack of understanding about how IP works.
If my machine, for example, does a DNS query to port 53 on your DNS server, it can use a more or less randomly assigned source port. If that source port happens to be 1434, then to respond to my query the DNS server will have to send a packet to port 1434.
Most systems don't use such low numbered ports for anonymous (aka. ephemeral) ports, but they can and some do. Filtering all traffic to udp port 1434 (or any particular udp or tcp port) is _NOT_ a good practice in general without knowing what is running on the hosts in question. However, it is unfortunately necessary at this time on many networks to deal with this worm.
This isn't limited to DNS, but any UDP query.
Not only that, but all too often they make "fixes" locally and never pass them on upstream.
Thanks guys.
A growing number of sites deny access to users under 13, or require special parent's permission to access them. This is a result of the COPPA legislation. So yes, you are right, you have more legal privacy protection then.
...but you are missing the detail that you won't be able to access a small, but well used, portion of the net, or you will have very restricted access to sites. Changing your birthdate later when you run into this isn't always possible.
In fact, Microsoft was actively contacting reporters to let them know about the issue and try to put their spin on it even before I released my exploit.
A number of Microsoft employees also leaked it to their friends after I reported it to Microsoft, and it started spreading from there.
And even Microsoft's lawyers were in on the gig of making sure everyone knew about it.
But seriously... Microsoft has been, and almost always is, very good about timely responses to security reports. Their problem is in dealing with them without having to be told by some Joe User that they have problems.
While I make this point in my paper, I just wanted to make sure people understood:
The real risk here isn't to hotmail or passport wallet (passport wallet isn't really an integral part of passport, just another service using it for authentication). It is to all things using passport. That isn't so much right now. But if Microsoft has their way, it will be. The sample exploit used Hotmail and Passport Wallet simply because they are commonly used services.
I would also like to note that Microsoft has been quite forthcoming with details and admitting the problems and fixing them. They are very good at being reactive. We will have to see how well this works going forward.
Well, ok, the particular protocol is. But the reality is there are a staggering number of (slightly) more specialized protocols designed to do exactly this.
Very interesting how "well used/abused" (depending on your perspective) HTTP is, and how stupid many firewalling policies are.
Wake up and smell the cookies. Although not entirely technically accurate or complete (because you could never get such a thing past a typical reporter), he is bang on.
Yes, they have a big bug. However, name a site, any site, that makes significant use of cookies and I can almost guaranatee you that you can steal cookies for that site using "cross site scripting". And that isn't going away.
It is _CRITICAL_ that sites properly manage their use of cookies to minimize the problems from people stealing cookies in whatever manner. That is the message that needs to be coming out here because that is the _ONLY_ thing that can reduce the risk for users in the long term.
However, be sure to note that the only reason this stops this particular exploit is because the page is coded to check for the browser. If it wasn't, then simply sending a different User-Agent would be no protection at all.
You don't need a bug in IE to do this. The 404 error page on www.blogger.com is vulnerable (the default 404 page on IIS5 is, or was, vulnerable), so any browser with javascript (or other scripting languages, or even some without) is vulnerable through "cross site scripting" exploits.
So, as I said before, sure this bug in IE is a pain but it isn't all that significant compared to the known issues out there...
Oh yea. Your page boils down to "letes invent a new very weak encryption scheme". Then you explain why encrypting the username and password don't do much good (ie. if they are what authenticates the user, then any user who gets that info is authenticated as the user) while ignoring the little point that your magic scheme suffers from the same problem!
It is pretty obvious that you can and should do something other than just sticking the password in a cookie, and most sites do. Then many sites, such as Amazon, still require you to enter your password before doing "important" things.
Thanks, but no thanks.
What are you talking about? "javascript in general can cause a security leak"? Huh? You don't make any sense. This has nothing to do with "javascript in general" and is 100% an IE implementation bug.
The only bug here is that you can make IE make requests with a Host: header that doesn't really resolve to the machine in question. So sure, there is some risk of cookies being exposed to the default vhost on a server when they should only be sent to a particular vhost, but that is a comparitively tiny risk.
But Navigator has a far bigger problem (allowing you to embed CRs and LFs within HTTP requests) that lets you do this or more. I posted about this some time ago on bugtraq. Unfortunately, Netscape doesn't give a damn. If you are looking at response to security issues, no matter how bad MS is, Netscape is 100 times worse. Combine a company with no direction and not much in the way of a production plan with most clueful employees having bailed out, with the remaining ones just not giving a damn... and that is what you get.
Sure, maybe it will work on some sites. But that is due to other holes that they have. Try it on amazon.com. You won't get far, since they require you enter your password to do that.
Umh... if you are running arbitrary javascript that can display the cookie, then it doesn't take any genius to figure out how to send it somewhere! Like... load a URL on the attacker's server (or a free throwaway account) containing the value of the cookie.
I have no idea what they did. I know that _I_ reported a very similar issue (possibly due to the same root problem) with the exact same consequences to Microsoft two months ago and they have not yet released a fix.
Sure, I got a quick response saying they were looking into it. Sure, they said they had developed a patch. But releasing it? Well... that didn't quite happen. It is true that I did not pressure them on it since I was busy with more important things, but I shouldn't have to.
Take a look at amazon's site. You can not enable one click ordering without knowing your password. You also can't do most account related things without knowing your password. This is done by Amazon on purpose.
Now, they _did_ have some pretty gaping bugs in this area a few months ago that let you bypass this. I pestered them enough and they eventually fixed them though.
Also note that one click ordering really isn't all that dangerous. It is more of an inconvenience. So what is the worst that can happen? You can get some item sent to you that you have the hassle of returning. You can't send it to a different address. You can't obtain the credit card info. etc.
Cookies are not secure and will never be secure.
First, ignore all the silly ranting about not being encrypted, etc. That has nothing to do with the issue. You can send cookies over SSL connections. You can set cookies that will only be sent over a SSL connection. etc. This type of cookie stealing problem is far easier to exploit than having to compromise the network over which traffic is flowing. That is a completely different attack that allows you to do a whole lot more than just steal cookies.
This particular vulnerability isn't actually all that "serious" in terms of new exposure. Lets look at the examples given on the page describing the exploit. hotmail, yahoo mail, amazon.com, etc... cookies for all those sites, and probably for every other site listed, are stealable anyway due to the so-called "cross site scripting" issue.
I have spent a lot of time with these issues and related ones over the past few months. By their very nature, cookies are not treated as confidential by the browser and are far too accessible. The only way to get rid of the problems that using cookies for authentication or private information have is to replace them with a mechanism that is designed from the ground up to protect that information.
Unfortunately, from the perspective of a web site creator, there are very very limited alternatives. HTTP basic authentication has its own problems, using SSL client side certificates has its own problems, MD5 digest auth has its own probems, etc. There is no current method that avoids all, or even most of, the problems. All you can do is manage your risk.
Some day I plan to write a document describing the various risks associated with authentication schemes and what can be done to minimize them, but that takes time...
I reported a similar bug to Microsoft on March 19th. My particular example was a URL in the form "http://10.0.0.1%20.msn.com/foo.html" which causes IE to load content from 10.0.0.1 but the Javascript code thinks it is .msn.com; this is a symptom of either the same problem or a very similar one.
However, they took their time to deal with it. I did not pressure them on it since I had more important things to worry about.
'nuff said?