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.

Praising security "investigators"

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.

yes, Rob.

We should outlaw being a jerk.

Then I would feel much less nervous, as a sysadmin.

- A.P.

--

Re:What Kinds of Malicious Code?

JavaScript is a relatively harmless language. While it could do something dramatic redirect the user to a porn site or display something obnoxious on the screen, I doubt that it would do anything like delete user's harddrives or give h@x0rs access to user's computers.

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:

• Users could be automatically whisked away to one of the results without seeing any of the other results in the list. So as long as you can get your page in the top ten results for a particular keyword, you can force the user to choose your page.
• Users are (understandably) expecting a Lycos page, so if the Javascript were to redirect the user to a page that masqueraded as a search-results page the user would be likely to assume that the page was legitimate and not biased. As an example, the "Church" of Scientology could use this bug to redirect users to an apparent Lycos results page for a search on "scientology" and they could change all of the results to be pro-scientology. Worse yet, they could change the links to anti-scientology sites to copies of the original sites which have been changed to something along the lines of "We've changed our minds. We were wrong. Scientology is not evil. All hail L Ron."
• For users of other Lycos services, such as Lycos mail, the user could be redirected to an imposter Lycos page which would ask for a username and password. Users would be much less likely to be suspicious because they were expecting a Lycos page.

Re:This is an incredibly common problem

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.

google is safe. Some WebMail sites affected

Some prominent web-based email sites like hotmail had a similar security-hole in their "dictionary" feature, which would allow a malicious user to paste an apparently harmless link in an email, because the link would be within the hotmail domain.

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)?"

Re:So?

Anyone who enables javascript is asking for trouble.

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

Re:javascript gripe

you can't just disable javascript's ability to open new windows whilst leaving the rest of its abilities intact. grrrr.

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

---

Javascript once again

This once again proof that running JavaScript on the client end is bad. I am one of those people who turn JavaScript off the most part, though there are one or two web-sites that I have to turn it on if I want to get beyond the first page. I would love it if Mozilla provided an option for only having JavaScript activated for certain sites.

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.

Jerks?

Finding security holes is exactly why open source security works better than security through osbcurity for crying out loud! You should be thanking those guys instead of using your site as a soap box to bully them into thinking like a Taco.

And re-read Steven Levy's book Hackers while you're at it.

--
Poliglut [poliglut.com]

[Off Topic] Re:What Kinds of Malicious Code?

Everything on XP runs as Administrator.

What FUD is this?

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 [microsoft.com]

What Kinds of Malicious Code?

JavaScript is a relatively harmless language. While it could do something dramatic redirect the user to a porn site or display something obnoxious on the screen, I doubt that it would do anything like delete user's harddrives or give h@x0rs access to user's computers.

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.

I checked google

The javascript hole doesn't work on google, but I found an even worse bug that allows you to pass along ASM [google.com] in a search string!

We love you anyway CT

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

Re:Jerks?

Are you stating that open source software is 100% secure?

People find holes in proprietary systems all the time. Hell, I've gotten a couple hundred MS security bulletins over the last 2 years sitting in my inbox, none of which MS has discovered on their own. The holes in proprietary systems simply get more exposure because it's fuel for all the open source zealots and a large part of corporate america uses the closed systems.

Moderators, can we please start marking messages that state "this wouldn't happen if it was open source" as "Troll".

Just to be an idiot and delve deeper into this arguement, are you stating that if it was open source, you'd do a line-by-line audit of the code to make sure it was something you felt was secure and you want to run? Let's face it, everybody that advocates open source just assumes everybody else is testing it. How many people have done a complete code audit of any Linux app before they installed it. None. This could also be due to the fact that most Linux apps haven't made it to that 1.0 mark yet and maybe the users expect what they get. It's a good argument that "it's still in BETA" when somebody points out a security hole in something.

Re:Javascript once again

That's one cool feature in Konqueror; it let's you turn of just the javascript window.opn function. So all of javascript works, but no pop-ups, pop-unders or whatever. It would be nice if the other browser manufacturers would let you turn off certain parts of javascript, but they're advertisers, too, so you know they won't.

Re:What Kinds of Malicious Code?

Windows boxen don't have root access. But I guess it doesn't sound as leet to say "You can 4Dm1n157r470r a Windows box!"

This is an incredibly common problem

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 &lt; and > with &gt; - problem solved :)