I'd like to take this opportunity to thank Caldera for offering a directed share program to selected individuals who participate in open source software. Yes, it appears to have been significantly smaller than previous such programs. But it did seem to be reasonably well run, offered fairly easy and well documented online access to participants in the US through Wit Capital and offered slightly more complicated access to some who are outside the US though other brokers.
Maybe going public is good for the company. Maybe it isn't. etc. But that is what any company that is going public faces. Regardless of if you think Caldera will succeed in their attempt or not or if they are worth their current valuation or not, I think that having them try is great for Linux and, if anything, makes them more accountable for adhering to the terms of the GPL, being a good community player, etc.
I am also glad that their stock didn't shoot through the roof on the first day like VA Linux did; now, even though LNUX is still at triple its offering price, many slam its stock performance as a failure, with little cause. As with all tech stocks, only time will tell what the company is really worth. In the meantime, it will trade at the whim of the market and associated spin doctors.
Hey! I invested $2.95 in this company some homeless guy told me was cool, then later someone tells me that doesn't mean I own the whole company!?! What is up with this! It is a ripoff! Call the SEC! The FBI! The FCC! CIA! ABC! NBC! SGI! DND! RCMP! CSIS! This is outrageous and they should all be quite upset that I was defrauded out of my $2.95.
Sheesh. IPOs are a more risky investment than many. That is why brokers like etrade put specific requirements on what investors can participate, since they are trying to keep out the people that don't have a clue about what an IPO is, how it works, how to read the details, what to look for, or what the risks are.
Erm... what the heck does etrade have to do with it? So, one broker won't let you participate. Caldera has zero control over that, and even if etrade did let you participate your chances of getting any shares allocated by etrade are very very low.
Just because one broker did not decide to give you a chance at any shares doesn't mean "you can't get in anyway".
Caldera's directed share program has far lower requirements.
If you are incapable of reading a prospectus (which contains a lot more important information than what percent of the stock is being offered), then you really shouldn't be investing in IPOs.
Generally, much of the information in them is very readable and is in plain english. Some of it does require knowledge to interpret, but that's just the way life is.
There are a huge number of caveats when buying IPOs at offering price, and simply stating what percent of the company is being offered, separately from the prospectus, makes little sense.
"if a server isn't vulnerable, how can you say it is?"
Well gee, probably because the statement that it isn't vulnerable is wrong. Why do you have any reason to think that Roxen magically avoids this problem by properly encoding things or stipping out HTML in every case? Why do you think there are no bugs in it?
And if you read the thread or the advisory, you would see that the vulnerability has nothing to do with "allowing people to post HTML tags in guestbooks". That is ancient news, although the problem is still amazingly common.
Except that this particular example does not exploit any "new" hole and does not really exploit the problem the advisory is talking about.
The advisory is not about pages that aren't smart enough to filter HTML that is entered by user A and displayed to user B.
In the other examples, the posting of the link is perfectly legitimate and there is no reason to reject it because it is just a simple link; the real problem is on the 404 page. In this example, slashdot should be doing a better job of filtering HTML.
If you think this is the same issue as a site having modified content on it because it mirrored another site that had modified content posted then you obviously read neither the advisory or the posts here.
Please don't post stupid comments without having any clue about what the facts are. Obviously the advisory is nothing new to people who don't read it or who don't understand what they read.
It is very true that not all webservers are impacted by this issue.
However, just because a company had not released information about their problems doesn't mean they don't have them. In Roxen's case, it has obvious issues, at least with the 404 page on the server at http://www.roxen.com/
The purpose of this post isn't to point at vendors and laugh, but to drive home the point that far more things are vulnerable than you may think. Apache, IIS, Netscape Enterprise (or whatever it is called now), Zeus, thttpd, WebSitePro... that should cover a majority of sites. Some are less vulnerable (Apache), some more (no names).
It is also important to remember that the webserver itself is only the smallest part of the issue. If the problem could be fixed by just patching your webserver, it would be nowhere near as big of an issue.
Well, then the cookie should contain the encrypted password. You can get the username (and all other personal info) just by accessing slashdot with that cookie.
Note that it isn't entering the URL that is the problem. I could enter a "normal" URL that redirects you to the same place. The problem here is that slashdot's 404 page doesn't encode the requested resource's name before outputting it. The only role that my posting the message with the link in served was the delivery method. There is no resaon for that to be slashdot itself, other than a lot of the people reading slashdot have accounts.
All you need is a single such page on a server, and a way to convince or force a user to follow an arbitrary link (and that is really pretty easy) and away you go.
As the advisory says, filter filter filter or encode encode encode. Unfortunately, it isn't as easy as it should be to do this properly.
The cookie contains everything you need to access slashdot as that user. It doesn't matter if you have their password if you can access the site as them.
It looks to be a userid and a crypt()ed password or something. But the details don't matter.
There is a problem with the change password feature on slashdot though; it should require you to enter your existing password. The way it is now, a user that has stolen your cookie can use it to change your password to something they know. No, not a huge difference between changing the password and just accessing the site as you, but...
The only reason that "notthere" is used for slashdot is because it goes to a 404 error page that includes the name of the document without encoding it. If this is done using SSIs, then applying the Apache patch on the Apache site will fix this by defaulting to entifying all SSI echo commands.
If you had a server with an older version of the Apache printenv, you could use/cgi-bin/printenv instead because it didn't properly encode its output.
Yes, it does work. There are cases where it doesn't work and various special circumstances that are sometimes needed to make it work, but it does work in a broad range of situations.
This is what the advisory is about and the essence of what the new issue is. It is the impact of this that hasn't been well understood before. The advisory isn't explicit about the details because that's just the way it is written, and the issue is very broad. But if you read it and understand what it is saying, it does include all the necessary concepts.
Suppose you want to exploit site A. What you have to do is find a page on site A that can echo back some part of the request unencoded and unfiltered. Then you send a user to that page. When they get the javascript back to them, their browser sees it as coming from site A and executes it. From there, you can control the user's interactions with the site however you want. Stealing cookies is only the most obvious way; the only reason this makes a reqest off to printenv on another server is to send the cookies out and show people they are being sent, in a URL encoded twice format.
If you wanted to apply this to Amazon, you could. However, you would have to find a different request to make. For example, on slashdot the 404 page doesn't properly encode its output. On amazon there are other pages that have the same problem. The site specific part is finding a page on the site (any page) that you can use.
For those that say "well, just don't click on any links with script tags in them", that doesn't change anything. I could send you to a page that redirects you there. I could do an onmouseover attribute to make you not see it. etc.
It also isn't hard to get many users to go to the URL you specify via other means, such as HTML email with the right stuff in.
One of the reasons so few people understand it is because they assume they know all the issues. Trust me, you almost certainly don't. Don't just read the title or the first paragraph of the advisory.
Read the full thing. The real issue is not obvious to most people until they have gone through it a few times and understand what it says. Read the info on the Apache site. Read the info from MS when it comes out. Understand it. Then come back and say this is the same thing as not filtering SSIs in guestbooks.
That would break a lot of valid things. Likely, on most sites, enough to make it worthless. In addition, filtering those characters is not always enough.
I have thought about possible fixes a lot over the past week. I haven't come up with anything that works too well yet other than simply having the developer make sure all their output is properly encodeded, where "properly" may be yet to be defined.
Do you ever do anything on the web that you would like to be private or restricted and not completely exposed to the world?
If not, you have no problem.
If you do things like online banking, shopping, etc. where your proof of identity matters or where there are real world implications, this could impact you.
This is important to note: this is not just a javascript issue. You can exploit this in various other ways, such as form tags, etc. Yes, it is harder and perhaps less rewarding. Disabling javascript does avoid much of the risk. But it is important not to think that this is a problem with javascript in particular.
Good idea. Unfortunately, it isn't so easy to implement. There are lots of ways to disguise this stuff and lots of valid things that could be caught so I really don't think it would work well. Feel free to prove me wrong...
I really don't think there is any magic bullet that the web server software can use to deal with this. Wish there was.
Do not follow this link. Warning: it will send any slashdot cookies that you have (ie. if you are logged in) to my web server, where they will be logged in the logs. The cookies will appear as the query string for printenv. No one else has access to the machine and I will not do anything with them, but can you trust me? But, if you are confident it can't be done, you have nothing to worry about. Javascript has to be enabled for this to work. Most of the people dismissing this problem don't realize the implications. (the link should come out properly, at least it previews right, but getting the right chars in there can be tricky sometimes...) DO NOT FOLLOW THIS
Even if slashdot filtered javascript: links (which are one of the things I mentioned in the Apache docs about htis issue), it would still be vulnerable. Remember, _ANY_ page on the server that doesn't properly encode output makes you vulnerable. In this case, an easy one is the default 404 page. Many webservers (well, most from what I have seen) do not properly filter URLs output on 404 pages. Apache did, but it didn't set an explicit charset so it was still vulnerable in some situations.
You are missing the issue. The issue is that this is not necessarily malicious code, but that this hole allows you to break through the partitioning between sites.
For example, one site should never be able to see cookies set by another site. By exploiting this hole, you can do things like this.
Yes, I have seen an example last week from (some big company) on one of the websites' front pages. Follow a link, and it sets a cookie that replaces the content on the front page with something else, persistently, until you delete the cookie. This was a real life example.
Slashdot Mirror
Yea, my math is wrong, thanks. Same point though. You can only compare percent changes.
I was given the option of asking for between 100 and 500.
I asked for 500 and received 250.
Others had different limits and allocations.
Huh? You have to look at percent change.
To buy 100 shares of MS you would need ~$100k, which would give you a profit of $600 on a 6 dollar per share rise.
With $100k, you could instead buy ~4350 shares of CALD at $23, which would give you a profit of ~$26000 on a 6 dollar per share rise.
ANd you say there is no difference? Suuuuuuuuure. Whatever. Go learn how the stock market works.
I'd like to take this opportunity to thank Caldera for offering a directed share program to selected individuals who participate in open source software. Yes, it appears to have been significantly smaller than previous such programs. But it did seem to be reasonably well run, offered fairly easy and well documented online access to participants in the US through Wit Capital and offered slightly more complicated access to some who are outside the US though other brokers.
Maybe going public is good for the company. Maybe it isn't. etc. But that is what any company that is going public faces. Regardless of if you think Caldera will succeed in their attempt or not or if they are worth their current valuation or not, I think that having them try is great for Linux and, if anything, makes them more accountable for adhering to the terms of the GPL, being a good community player, etc.
I am also glad that their stock didn't shoot through the roof on the first day like VA Linux did; now, even though LNUX is still at triple its offering price, many slam its stock performance as a failure, with little cause. As with all tech stocks, only time will tell what the company is really worth. In the meantime, it will trade at the whim of the market and associated spin doctors.
Hey! I invested $2.95 in this company some homeless guy told me was cool, then later someone tells me that doesn't mean I own the whole company!?! What is up with this! It is a ripoff! Call the SEC! The FBI! The FCC! CIA! ABC! NBC! SGI! DND! RCMP! CSIS! This is outrageous and they should all be quite upset that I was defrauded out of my $2.95.
Sheesh. IPOs are a more risky investment than many. That is why brokers like etrade put specific requirements on what investors can participate, since they are trying to keep out the people that don't have a clue about what an IPO is, how it works, how to read the details, what to look for, or what the risks are.
Erm... what the heck does etrade have to do with it? So, one broker won't let you participate. Caldera has zero control over that, and even if etrade did let you participate your chances of getting any shares allocated by etrade are very very low.
Just because one broker did not decide to give you a chance at any shares doesn't mean "you can't get in anyway".
Caldera's directed share program has far lower requirements.
If you are incapable of reading a prospectus (which contains a lot more important information than what percent of the stock is being offered), then you really shouldn't be investing in IPOs.
Generally, much of the information in them is very readable and is in plain english. Some of it does require knowledge to interpret, but that's just the way life is.
There are a huge number of caveats when buying IPOs at offering price, and simply stating what percent of the company is being offered, separately from the prospectus, makes little sense.
Anyone take a look at the slashdot.org whois lately? Sure looks hijacked to me...
Registrant:
Andover.net (SLASHDOT5-DOM)
50 Nagog Park
Acton, MA 01720
Domain Name: SLASHDOT.ORG
Administrative Contact:
Malda, Rob (RM7054) slashdot121@HOTMAIL.COM
616-994-0441
Technical Contact, Zone Contact:
DNS Administrator - HyperMart (DA3706-ORG) dns-admin@HYPERMART.NET
206.447.1595
Fax- - 206.447.1625
Billing Contact:
Malda, Rob (RM7054) slashdot121@HOTMAIL.COM
616-994-0441
Record last updated on 07-Feb-2000.
Record created on 01-Feb-2000.
Database last updated on 8-Feb-2000 14:38:52 EST.
Domain servers in listed order:
NS1.HYPERMART.NET 206.253.222.65
NS2.HYPERMART.NET 206.253.222.66
"if a server isn't vulnerable, how can you say it is?"
Well gee, probably because the statement that it isn't vulnerable is wrong. Why do you have any reason to think that Roxen magically avoids this problem by properly encoding things or stipping out HTML in every case? Why do you think there are no bugs in it?
And if you read the thread or the advisory, you would see that the vulnerability has nothing to do with "allowing people to post HTML tags in guestbooks". That is ancient news, although the problem is still amazingly common.
Here is one very easy to find example: the most obvious example
Except that this particular example does not exploit any "new" hole and does not really exploit the problem the advisory is talking about.
The advisory is not about pages that aren't smart enough to filter HTML that is entered by user A and displayed to user B.
In the other examples, the posting of the link is perfectly legitimate and there is no reason to reject it because it is just a simple link; the real problem is on the 404 page. In this example, slashdot should be doing a better job of filtering HTML.
If you think this is the same issue as a site having modified content on it because it mirrored another site that had modified content posted then you obviously read neither the advisory or the posts here.
Please don't post stupid comments without having any clue about what the facts are. Obviously the advisory is nothing new to people who don't read it or who don't understand what they read.
It is very true that not all webservers are impacted by this issue.
However, just because a company had not released information about their problems doesn't mean they don't have them. In Roxen's case, it has obvious issues, at least with the 404 page on the server at http://www.roxen.com/
The purpose of this post isn't to point at vendors and laugh, but to drive home the point that far more things are vulnerable than you may think. Apache, IIS, Netscape Enterprise (or whatever it is called now), Zeus, thttpd, WebSitePro... that should cover a majority of sites. Some are less vulnerable (Apache), some more (no names).
It is also important to remember that the webserver itself is only the smallest part of the issue. If the problem could be fixed by just patching your webserver, it would be nowhere near as big of an issue.
Well, then the cookie should contain the encrypted password. You can get the username (and all other personal info) just by accessing slashdot with that cookie.
Note that it isn't entering the URL that is the problem. I could enter a "normal" URL that redirects you to the same place. The problem here is that slashdot's 404 page doesn't encode the requested resource's name before outputting it. The only role that my posting the message with the link in served was the delivery method. There is no resaon for that to be slashdot itself, other than a lot of the people reading slashdot have accounts.
All you need is a single such page on a server, and a way to convince or force a user to follow an arbitrary link (and that is really pretty easy) and away you go.
As the advisory says, filter filter filter or encode encode encode. Unfortunately, it isn't as easy as it should be to do this properly.
The cookie contains everything you need to access slashdot as that user. It doesn't matter if you have their password if you can access the site as them.
It looks to be a userid and a crypt()ed password or something. But the details don't matter.
There is a problem with the change password feature on slashdot though; it should require you to enter your existing password. The way it is now, a user that has stolen your cookie can use it to change your password to something they know. No, not a huge difference between changing the password and just accessing the site as you, but...
The only reason that "notthere" is used for slashdot is because it goes to a 404 error page that includes the name of the document without encoding it. If this is done using SSIs, then applying the Apache patch on the Apache site will fix this by defaulting to entifying all SSI echo commands.
/cgi-bin/printenv instead because it didn't properly encode its output.
If you had a server with an older version of the Apache printenv, you could use
etc. This is a site dependent thing.
Yes, it does work. There are cases where it doesn't work and various special circumstances that are sometimes needed to make it work, but it does work in a broad range of situations.
This is what the advisory is about and the essence of what the new issue is. It is the impact of this that hasn't been well understood before. The advisory isn't explicit about the details because that's just the way it is written, and the issue is very broad. But if you read it and understand what it is saying, it does include all the necessary concepts.
Suppose you want to exploit site A. What you have to do is find a page on site A that can echo back some part of the request unencoded and unfiltered. Then you send a user to that page. When they get the javascript back to them, their browser sees it as coming from site A and executes it. From there, you can control the user's interactions with the site however you want. Stealing cookies is only the most obvious way; the only reason this makes a reqest off to printenv on another server is to send the cookies out and show people they are being sent, in a URL encoded twice format.
If you wanted to apply this to Amazon, you could. However, you would have to find a different request to make. For example, on slashdot the 404 page doesn't properly encode its output. On amazon there are other pages that have the same problem. The site specific part is finding a page on the site (any page) that you can use.
For those that say "well, just don't click on any links with script tags in them", that doesn't change anything. I could send you to a page that redirects you there. I could do an onmouseover attribute to make you not see it. etc.
It also isn't hard to get many users to go to the URL you specify via other means, such as HTML email with the right stuff in.
One of the reasons so few people understand it is because they assume they know all the issues. Trust me, you almost certainly don't. Don't just read the title or the first paragraph of the advisory.
Read the full thing. The real issue is not obvious to most people until they have gone through it a few times and understand what it says. Read the info on the Apache site. Read the info from MS when it comes out. Understand it. Then come back and say this is the same thing as not filtering SSIs in guestbooks.
That would break a lot of valid things. Likely, on most sites, enough to make it worthless. In addition, filtering those characters is not always enough.
I have thought about possible fixes a lot over the past week. I haven't come up with anything that works too well yet other than simply having the developer make sure all their output is properly encodeded, where "properly" may be yet to be defined.
Do you ever do anything on the web that you would like to be private or restricted and not completely exposed to the world?
If not, you have no problem.
If you do things like online banking, shopping, etc. where your proof of identity matters or where there are real world implications, this could impact you.
This is important to note: this is not just a javascript issue. You can exploit this in various other ways, such as form tags, etc. Yes, it is harder and perhaps less rewarding. Disabling javascript does avoid much of the risk. But it is important not to think that this is a problem with javascript in particular.
Good idea. Unfortunately, it isn't so easy to implement. There are lots of ways to disguise this stuff and lots of valid things that could be caught so I really don't think it would work well. Feel free to prove me wrong...
I really don't think there is any magic bullet that the web server software can use to deal with this. Wish there was.
Do not follow this link. Warning: it will send any slashdot cookies that you have (ie. if you are logged in) to my web server, where they will be logged in the logs. The cookies will appear as the query string for printenv. No one else has access to the machine and I will not do anything with them, but can you trust me? But, if you are confident it can't be done, you have nothing to worry about. Javascript has to be enabled for this to work. Most of the people dismissing this problem don't realize the implications. (the link should come out properly, at least it previews right, but getting the right chars in there can be tricky sometimes...) DO NOT FOLLOW THIS
through. Now, when I tried it, slashdot didn't accept it, but that is another issue.
Some browsers (especially IE) allow lots of attributes to lots of tags that you wouldn't normally think of as dangerous.
Even if slashdot filtered javascript: links (which are one of the things I mentioned in the Apache docs about htis issue), it would still be vulnerable. Remember, _ANY_ page on the server that doesn't properly encode output makes you vulnerable. In this case, an easy one is the default 404 page. Many webservers (well, most from what I have seen) do not properly filter URLs output on 404 pages. Apache did, but it didn't set an explicit charset so it was still vulnerable in some situations.
You are missing the issue. The issue is that this is not necessarily malicious code, but that this hole allows you to break through the partitioning between sites.
For example, one site should never be able to see cookies set by another site. By exploiting this hole, you can do things like this.
Yes, I have seen an example last week from (some big company) on one of the websites' front pages. Follow a link, and it sets a cookie that replaces the content on the front page with something else, persistently, until you delete the cookie. This was a real life example.