The Linux Security Circus: On GUI isolation

One solution to this vulnerability is to put your browser in a virtual machine. Testing this idea with VirtualBox on Fedora 14 verifies that a user inside the VM does not have access to X events outside the VM.

Thus, by putting your browser inside a VM sandbox, the best the cracker could do is compromise your sandbox. Nothing lost except your browser environment, cookies, favorites. Your valuable user data remains out of reach.

Cookies are actually very valuable, as they contain lots of user information. This information contains session keys to websites (this is why I recommend you always to logout), which hackers really like.

Anyway, I just think the whole web has to be redesigned.

Penguinist: But that's the whole issue: The 'valuable user data' is entered via the browser! Credit card numbers, e-banking, which site you visit, your browser handles all of it; so 'sandboxing' your valuable data and then using that same valuable sandbox to communicate valuable data is of no help. That's what I was trying to explain.

hkwint and jimbauwens: What I had understood from this discussion was that it was at least theoretically possible for a javascript/browser attack to gain access to keystroke events. Is this true? If yes, then I would want my terminal sessions to be running in a different context as my browser. Running su - in an xterm could expose a lot more than cookies if a keystroke monitor was watching.

Well, not really, but if an exploit is found (and many are being found each week), it just takes 1 person to write the software, and steal keystroke events. My point is that JavaScript is a very powerful language, and maybe to powerful to use for the web.

Well, actually, I could make some JavaScript code that scans for your router type, and if its a certain type, for example one that can be updated, it would flash a new firmware that would sniff the network packets. Since it is a router, all the important data, such cookies, authentication passwords, emails, etc goes through it, and will be in the hands of the hacker. Just through some JavaScript, the attacker got full access to your LAN. This is also a reason why to use encryption for many things (HTTPS, SSH, etc), because you never know who might be looking.

@ jimbauwens:

All the more reason to flash your own router with custom firmware...

My router is anything but stock...

> All the more reason to flash your own router with custom firmware...

Does that do anything to prevent the router being re-flashed? Though I'd think resetting the admin password would be enough, even with a stock router.

Yup, changing the router password should do the trick . But if you want to be really sure, you should disable the web interface, or use a custom firmware, just like JaseP.

The flashing utility for custom firmwares & the binary packages used are, for the most part, different from the stock ones. Best solution to increased capabilities & security on a router is to get one that can be flashed with open source firmware. A stock Linksys/Cisco WRT54GL can be flashed with any number of firmwares,... Many being derivatives of OpenWRT or DD-WRT, & some of those can be made to run intrusion detection software.

[url=http://lifehacker.com/ #!178132/hack-attack-turn-your-60-router-into-a-600-router]Check Here for an old article[/url]

> Yup, changing the router password should do the trick .

Thanks for confirming that. That's one of the standard things I do when setting up a router.

> But if you want to be really sure, you should disable the web interface, or use a custom firmware, just like JaseP.

None of our routers are high enough on the food chain to allow a custom firmware, and I use the web interface fairly frequently, so disabling it isn't really an option either. :(

> The flashing utility for custom firmwares & the binary packages used are, for the most part, different from the stock ones.

OK. That's good to know. Thanks for the information. I (naively) assumed the flash procedure was hardware based and would therefore stay the same.

Most routers can be flashed through the web interface, (and for some you even don't need the admin pass, so long you know the right url). The custom firmware's that I know don't have this, you have to do it through the commandline (through SSH or serial), so there is basically no change for a website to hijack the router this way.

And just to note: no one has created an evil script like this yet, so don't worry to much :)

But Jim, you're an 18 (plus) year old with the skill set of a greybeard. Imagine one like yourself with less moral restraint...

Thanks for the compliment :D

I think the ones with 'less moral restraint' will be writing windows viruses, and not looking at something so simple as 'web browsers'. But I don't know, there might always be one person that wants to do something like this.

Quoting: But I don't know, there might always be one person that wants to do something like this.

There's about 7 Bil people in the world (double the population from when I was born),... I'm sure there's one out there, somewhere.

Yeah, I think a botnet of routers would do great for DDOS.

Yeah, didn't think about that. And anyway, the problem with this is that it is a design flaw, not a bug. And this makes it allot more hard to fix .. if it is fixable.

It's fixable. But the fix requires router firmware updates & modification of the Java & Javascript run-time libraries to dis-allow that kind of intrusion (limits on functionality). It may break some websites (maybe quiet a few, actually). But hey, medicine can be bitter.

Yes that is true, and I think the only way of getting it fixed is by making it (the 'exploit') and publishing it. Other wise they just will ignore you (like Mozilla and Google have done with me).

Be diplomatic and do it through a publication with a thorough write-up. Also, do not finish the entire exploit. Make it more a proof of concept thing, obvious to those with the skill set to finish it up, but difficult for a "script kiddie" to use. Also you might want to provide suggestions for a non-invasive fix (Java/Javascript library restrictions & simple routines for firmware fixes that would be easy to implement). ... Otherwise, you run the risk of looking like a black hat, & the stigma that comes fom it. After all, you wanna get PAID for doing this kind of work inthe future, don't you?!?!

Of course I want to be paid for doing this kind of work, as I spend lots of time working on it. But I'll have to make it another time, exams are holding me back ;)

And you make a good point on how I should release it, thanks for that!