Security Hole Lets Lycos Run Arbitrary JavaScript
JibbaJabba writes "Securiteam is reporting that a "security vulnerability has been confirmed in Lycos's Search Engine" which "allows malicious web site owners to cause JavaScript code (or any other HTML code) to get included in the search results displayed to the end user by Lycos". They also state that "other engines are suspected to be vulnerable as well". Anyone tried google yet? The original bugtraq report by Sentry Labs is available here." Proof once again that the jerks have more spare time then the people who actually do something worthwhile.
I don't think I'm buying into this "they are only showing you how bad your stupid code is." reasoning anymore. ALL code is flawed, so taking advantage of it is like pushing down someone you meet on the sidewalk and saying "I am only showing you how poor your center of gravity and sense of balance are!" No, that is not a reasonable line of thinking. If you want to make something better, show the makers what's wrong, and post publicly if it is not taken care of. all of the rest of this is some kind of ego-run-amuck b.s. about trying to _be_ "Neo" hacking "the man". and it is _very_ juvinile. I spend FAR too much of my time trying to make sure that my servers are pactched and my virus files are up to date and my users are not sending out company data to outside sources that don't need to know. It takes away from a sys. adim's time that _should_ be spent watching company information flow and user environments to look for ways to help it improve the company. NOT making sure that the 13 year old kid that just got out of school isn't making sure I know that IIS has a buffer overflow problem that gives him all of my customer's credit cards. Not ALL information was meant to be free. If you disagree please feel free to apply for wireless service from verizon or AT&T and learn all about how "helpfull" these "security advisors" really are.
- A.P.
--
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Then I would feel much less nervous, as a sysadmin.
- A.P.
--
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I don't think there there is another means presently known to redirect the user directly from the list of results within a search engine before the user ever actually clicks on any of the results. Maybe you misunderstood what I wrote or I wasn't clear in what I meant - or maybe I'm misunderstanding you now. How can you go about redirecting users from the page within the search engine that shows the first few results without using this Javascript exploit?
How the things that I listed differ from the things listed by the original poster are that the original poster considered the most nefarious possibility of redirection to be an annoyance (in the same way that porn sites flood you with annoying popups [from what I've heard]) whereas I suggested that a much worse use of redirection would be to deceive the user. The key is that the user thinks he is still on Lycos when he is not and this opens up a whole can of worms. Perhaps you consider this "harmless" because you think people who don't look up at the URL location of each web page they visit are stupid, but when you click on the "Search" button of your favorite search engine how many times do you look up at the location to see that the results are indeed from where you expect?
The third possibility you mention is not likely at all to work as people don't have to login to use a search engine.
Lycos does have web based email, which quite a few people use, and I think they have some other services that require registration as well. I would wager (based on Bayes' theorom) that people using Lycos for searching are more likely to have Lycos webmail accounts than the average internet user.
-----
Free P2P Backup, Windows & Linux
Redirection could be used for more than just annoying purposes. The thought can comes to my mind right away is that it could be used for deceptive purposes:
-----
Free P2P Backup, Windows & Linux
Great job, you really addressed 90% of the issues with stupid CGI programmers. I have dealt with the same problem in CGI that I've "inherited", and it's a pain in the ass to see such a simple exploit go unpatched.
Unfortunately, the Lycos bug is exactly the opposite. Instead of them taking s, and failing to turn them into < and >, the problem is that Lycos is finding web pages with < and >, and turning them into , thus changing non-HTML into HTML. A much less common problem, and also one it seems like they have TRIED to create. Why parse the HTML symbol codes into the symbols they represent? It's a strange bug, and its obscurity is why it's taken so long to come to light.
One thing to note, though, is that this bug probably would have been found months, if not years, ago if Lycos was OSS.
The danger comes from sites that base their authentication schemes on persistent cookies after the user has signed-on once.
Such cookie basically tells the server "hey i'm the right guy now gimme my personalized page".
You can use javascript to sniff the cookie via document.cookie and send that value to a cgi script that'll store it.
heh fun.
Extraordinary Vacations. Exceptional Prices
Once the user would click on that link, it would take them to the spell-checker interface of hotmail, but the 'word' passed to that CGI is actually HTMLcode that gets "echo'ed" as part of the "result page", just like any dictionary interface would do. That HTML code could be a SCRIPT tag downloading a .js javascript file from the perpetrator's server (to keep it clean) which could very well sniff a user's document.cookie and change the location of some hidden image on the page or pop a window by making an HTTP request to some evil CGI and passing the value of that document.cookie string as a parameter and store it in some text file.
The victim's cookie string most likely contains information that tells the server "hey i'm authenticated" so all it takes is for the evil person to reproduce that cookie.
As I browse the web, I find such vulnerabilities on member-driven sites all the time, some times I warn the webmaster, some times I don't bother, but it can potentially be pretty nasty. I even got a t-shirt from some mildly popular online community fedexed to me once after I rode their asses likes a madman so they'd finally plug a really *really* bad similar hole.
I found one in some remote feature of yahoo a few weeks ago, but its very small and I doubt anyone else would find it.
The rule of thumb to always follow as you design your web application, is "what is that HTML i'm sending to the user made of?". "is there any content in there that is taken from any kind of user input?". "if yes, am I filtering out all angled brackets?". "if i am allowing for user-input HTML content, am i filtering all unnecessary tags and among the tags i'm allowing am i filtering all unnecessary attributes (onload,onmouseover,onclick)?"
Extraordinary Vacations. Exceptional Prices
A troll, on the other hand, is sometimes disguised as a somewhat coherent expression of opinion but doesn't really represent the poster's opinion, it's just designed to get a lot of people worked up replying to it so that the original poster can laugh at them wasting their time and tell himself how clever he is for having done so.
What they have in common is the level of maturity (low) and the lack of positive contribution to the discussion.
And then there are the 12 year olds who keep trying to sneak in links to stuff other than that to which the link appears to lead, and all the other posts associated with those posts, which are just another immature attempt to annoy people and waste their time. Off-topic covers these just fine.
None of this necessarily has anything to do with how posts actually get moderated.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
That's a bit disingenuous. JavasCrypt is enabled by default in all graphical browsers. 90% of people out there don't even know what it is, much less how to turn it off (turning it off in Netscape is fairly easy, but turning it off in IE is extremely non-obvious, even if you know you're looking to kill JavaScript).
Schwab
Editor, A1-AAA AmeriCaptions
Wait a sec. If girls only go out with jerks, and never with "nice guys," that would mean that sys admins would be getting all the girls. And I know that ain't so.
That's it. End of story. If browsers let you do that, we'd all be happy.
What? I can't? Shoot, I'd better turn that off then! :-)
Konqueror has exactly this option - you can tell it to disallow opening new windows completely, to have it ask, or to allow javascript window.open() always. Handy little feature...
---
Hacker Public Radio is our Friend
"Search warrant."
Fly away, little BSA bird.
I am very small, utmostly microscopic.
Hyper Text Markup Language
it's a stateless language, but a language nonetheless.
Just raise the taxes on crack.
jeez, thank goodness you're on the good side, or at least it would seem..
Just raise the taxes on crack.
I am a believer in the thin-client approach to web-pages and that is if you can't do it on the server and you can't use HTML for your web page then you are probably doing something wrong. This is my opinion and you don't have to share in it.
Jumpstart the tartan drive.
And re-read Steven Levy's book Hackers while you're at it.
--
Poliglut
How does *Microsoft* force you to enable cookies to view *Starbucks*?! Cookies were invented by Netscape anyway, you know, and there's absolutely nothing unsafe or strange about them despite all the FUD.
/something.php3 becomes /something.php3?youAre=dude123 and every link adds that ?youAre=dude123 part to it. You can now be identified between link clicks. 99% of all cookies are simply used for session tracking. Only idiots programmers would actually store any DATA of relevance in them (like a credit card number, home address etc.)
A cookie set by a server can only be read by that same server. The exact same effect can be done by URL rewriting (adding a token to each url.. as in..
Not all the facts were stated by the person to which you replied. Windows XP Home Edition does not feature different access levels. All users are Administrators. Windows XP Professional retains different access levels.
See: http://www.microsoft.com/windowsxp/guide/compariso n.asp
"Be Happy or Die." -- AoN
don't forget to change a quote (") into "
And it might also be a good idea to turn & into & while you're at it.
Btw, I don't think you need to do the < and > transformations for attributes, but it doesn't hurt.
The shareholder is always right.
This link is a fine example... difficult to get out of on Microsoft browsers.
Only on Microsoft browsers? I don't remember finding a browser where I could get out of that kind of loop.
See bug 59314, "Alerts should be content-modal, not window-modal", for fixing this in Mozilla.
The shareholder is always right.
Cmon, that's just sloppy.
:).
<? $page_description = strip_tags($page_description);?>
Problem solved.
I love PHP
You also forgot that you need to remove quotes as well.
When it helpfully fills in a text box, you have to escape the quotes. Take this example:
Now we craft the malicious string ( " onfocus="alert('howdy'); ) and place it in the text box like so:
See also my article on Accepting input and malicious script insertion.
Lots of sites are vulnerable. Lots of sites have lazy developers.
and that quote illustrates why. If you live in a small town where nobody locks the doors, it's not reasonable to walk into someone's house uninvited. If you connect your computer to a global network and program it to accept TCP connections on certain ports, it is reasonable for people all over the world to connect to those ports.
I wonder if Stoll originated the nonsensical comparison between 'unauthorized access' of a corporate/governmental computer and breaking into someone's house. They're not the same at all, but this silly notion underpins a lot of bad thinking and bad law. Stoll was zealously protective of the 'computing resources' of a huge government lab at a time when 'real computers' were out of reach for ordinary people. He could be compared to a royal chef in the middle ages urinating on the excess food from the royal table lest a commoner eat it.
I don't agree that security problems have made the web 'experts only'. If you want to run your own web server and you're not an expert, run vanilla Apache and sshd and nothing else. Actual holes in Apache are pretty rare. Or am I missing your point?
This article was just posted, but then disappeared from the home page. Interesting.
Got Rhinos?
This isn't a serious security breech, just an annoying oversight by Lycos programmers which will probably be patched up in the next fifteen seconds.
Got Rhinos?
The javascript hole doesn't work on google, but I found an even worse bug that allows you to pass along ASM in a search string!
*sigh*
In the context of the browser VBScript executes with the same permissions as JavaScript... PERIOD!
You cant create a file system object using a VBScript in a browser. It takes more than most people think to damage a machine with just VB/JavaScript. You have to use "social" engieering more than anything and trick people more than you cna directly harm their systems.. think about it
Why don't you show me some VBScript runs from a web page that can do something malicious. Ill gladly run it on my machine and click NO if its an ActiveX object and simply laugh at anything else since it simply WONT work in the browser.
Outlook has totally different access privileges why do you think all of these worms are spread. Do you know the mayhem that would be caused if ever IE browser was exploitable via VBScript?
Stop and think before trashing something for an unfounded reason.
Jeremy
I think a lot of those of us who post to slashdot would be in trouble if jerks were outlawed.
I'd certainly flee to Canada if that happened.
But then Canada would be populated with jerks...
Perhaps we could all flee to Australia? Then Australia would have THREE social classes -- descendants of British "criminals," aborigines, AND jerks!
Bah, nevermind...
That's a bit disingenuous. JavasCrypt is enabled by default in all graphical browsers.
Actually that's not quite true. Konqueror very deliberately keeps JavaScript, Java and Netscape plugins off by default. If you need them, then it's a cinch to enable them (very obvious in the Konqui settings dialog, or, if you have the extra plugins that are in the kdenonbeta package, it's even simpler, select a menu item or a toolbar button).
If you're concerned about turning JavaScript on globally, then you can enable/disable JavaScript (and Java) on a per-site basis.
Sigh... If only every graphical browser put security first...
"Proof once again that the jerks have more spare time then the people who actually do something worthwhile."
Don't be so hard on yourself there CmdrTaco! We read your drivelous comments just the same 8^}
And BTW - it's 'than' the people, not 'then' the people.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
And if you're putting the results in <INPUT TYPE="TEXT" VALUE="Something The Use Entered"> don't forget to change a quote (") into ". Otherwise you can still get weird results, especially because you can insert new attributes (maybe do something even via onclick="something_nasty()" at that!)
--
You are in a maze of twisty little relative jumps, all alike.
For the love of Jebus, with all the ways JavaScript can be abused, why don't the browsers come with a way to filter out the most obnoxious actions? I'd love to see checkboxes for the following.
Disallow new window creation
Disallow window moving and resizing
Disallow redirection
Disallow shortcut creation
[I nearly blew a gasket the first time I found that a site had placed porn and casino links in my Start menu.]
Disallow access to cookies
There are probably others, I'm no JavaScript whiz.
An ideal browser would let you toggle all that stuff, and then enable it for specific sites of your choosing.
I'll have to look at Web Washer again... maybe it lets you re-enable pops for the sites that need them.
<a href="friskit.com"> <img border=0 src="http://friskit.com/site/images/logo.gif"> </a> <script> document.body.style.filter= "progid:DXImageTransform.Microsoft.Blur (pixelradius=3)"; </script>
My boss just asked me if I could look into directing traffic to our website.
Knowing this, I could index all of our pages with porn keywords and redirect users to our page selling Office Furniture!!!
I'll be sure I send out OfficeFurniture.vbs just in case Lycos fixes this hole before I get a chance at a promotion.
"Communism is like having one [local] phone company " - Lenny Bruce
Combine this with the payola that puts certain for-a-fee pr0n sites at the top of the list, and little Timmy doing a search for his latest book report on "naked singularity" is going to have 20 very confusing new windows pop up on his screen that make him have strange feelings faster than you can say "Tentpole".
Second, for everyone who's saying how harmless JavaScript is, you're somewhat right, but it doesn't matter. Why? Because the person releasing the vulnerability was just using JavaScript as an example. It could also be VBScript, just as easily...and THAT is NOT harmless by any stretch of the imagination. Imagine doing a search on Lycos, and getting smacked with a new variant of KAK.
For your security, this post has been encrypted with ROT-13, twice.
JS on the other side, hasn't an easy way to access sensitive data or create malicious code. As someone noted before, you can redirect the user to a porn site or something, but its rather dificult (I'm not a JS programmer, just done a couple of hacks with it) to access to sensitive information, such as the hard drive
Make It Secret . Free JavaScript implementation of AES for your browser
The simple fact is that content you get from the Internet, be it Slashdot, Lycos, Microsoft, or anything else, may have been altered or may be malicious in itself. If you care about it, you have to deal with it by picking your web client to protect you; trying to insist that every web site is secure and trustworthy is a losing battle.
BTW, from the description of the bug, JavaScript is the least you have to worry about. ActiveX controls would seem like a much bigger problem. And web sites that server user-supplied JavaScript through SSL are also a much bigger worry (since the user-supplied JavaScript is implicitly signed with the site certificate); at least Lycos doesn't serve its content through SSL.
This one's been around for years, and is present on literally millions of sites. I read somewhere certain both AltaVista and Amazon have both suffered from this in the past. Here's how it works:
:)
You have some kind of form input, with the next page displaying whatever the user typed into that form field (for a search engine this would be in the form of "You searched for..."). the golden rule of web development is NEVER TRUST input from your users. Most developers take great lengths to check anything that's going into a file or database, or erspecially code that will be executed on the command line.
However, if you're just going to display something to the user that typed it why bother checking the content? Surely only the user who typed the thing is going to see it again, and it's not like they're going to be able to affect any of your systems?
Therein lies the problem. If you allow a user to type anything into a form and then have it re-displayed, they can include HTML tags. And if they can include HTML tags, they can include <script> tags. And script tags can do weird stuff.
Still think it's not a problem thanks to the fact that only the user will see it? Think again - seeing as most applications like search engines use GET to pass parameters, you can fill in the form for the user by offering them a link to click:
http://yoursite.com/search?<b>Oooh+Bold+Text </b><script>alert('Ew ww nasty popup')</script>
All of a sudden you can cause your weird popup messages to appear on someone elses site.<p>
The biggest security problem is the fact that javascript can access cookies. Imagine sending someone to a website via a link containing javascript that reads their username/password cookie for that site then pops up a window feeding that username/password to a script page con your server (in the query string) - BANG, you've got their password.
How do you stop this happening? Simple - deactivate HTML tags from user input by replacing < with < and > with > - problem solved