I wonder what is being done about this
|
| Author | Content |
|---|---|
| tracyanne Apr 24, 2011 7:24 PM EDT |
nt |
| jhansonxi Apr 24, 2011 8:21 PM EDT |
It's a very old problem with most GUI environments. I was aware of the Windows problem a decade or so ago. I'm surprised they did anything to limit it. It's a hard problem to solve without adding more overhead. It's not much of a risk unless the security context is different between the GUI apps you're using, like being logged in as a normal user account and also have a root terminal running. With the move towards getting X entirely into user space it will be interesting to see if this problem is mitigated any. |
| 750 Apr 25, 2011 9:28 AM EDT |
i fear the Linux security focus is too much on root account access limiting. These days, at least on desktops where most X use is, the target is whatever data is inside the user account. Things like credit card statements and bank account info, or anything else that can allow identity fraud. Not sure how much this compromises the old defense of running the web browser on a different user account then the rest of the DE tho. |
| JaseP Apr 26, 2011 8:57 AM EDT |
Correct me if I am wrong about this,... But, this would be a local vulnerability only, since any app that exploited this would still need to have been installed locally?!?! Java (& Java Script), for example, runs in its own sandbox, right?!?! So the big threat would be to kiosk-type machines with dodgy security in its running apps?!?! Right?!?! |
| jdixon Apr 26, 2011 10:23 AM EDT |
> But, this would be a local vulnerability only... Depends on whether you allow remote X sessions or not. Most distros I know of default to not allowing them, so in most cases, yes. However, even in that case where they are allowed, it's still a local user vulnerability, which is probably what you mean. |
| JaseP Apr 26, 2011 10:47 AM EDT |
Yeah, that's what I mean. And yes, I personally do not allow remote X sessions on my machines. Plus, a lot of "features" in apps that extend the usefulness of other apps exploit this hole... I'm sure. Closing it would mean rre-writing those. I can see the need on mission critcal machines (miilitary, etc.), but don't see a big return for the effort otherwise. |
| gus3 Apr 26, 2011 11:53 AM EDT |
$ ssh -Y compromised-remote The remote has been hacked, and the Bash profile has launched an X listener in the background, unknown to the user. PWN3D, game over. It isn't "local vulnerability only". |
| jdixon Apr 26, 2011 12:18 PM EDT |
> It isn't "local vulnerability only". No, but it requires a local user account to initiate the ssh session. Which is what I meant. |
| JaseP Apr 26, 2011 2:12 PM EDT |
Quoting: $ ssh -Y compromised-remote You need to have a user account, as jdixon said, and THAT on a machine where you're allowing SSH, not fire-walled off or anything. A person, having ssh'd in & mucking about in a user account can do a lot more damage or use any number of techniques to escalate privileges. So, what you'll get with this is user access to one machine, after you pretty much have it already. I guess my point is that you're saying, "If you leave you're barn door open (ssh), & don't tie up your horse (X-server),... I can come in & steal your horse..." I'm saying, "Yeah, IF I leave my barn door open,... But if I did that, you could do a lot worse stuff too..." |
| gus3 Apr 26, 2011 3:43 PM EDT |
Quoting:A person, having ssh'd in & mucking about in a user account can do a lot more damage or use any number of techniques to escalate privileges.Having sniffed a root password (possibly to another system, or even systems!) is much more valuable than "mucking about and doing damage". Silent, stealthy root access is worth money in the underground. Mucking about is good only for ego-stroking. |
| hkwint Apr 26, 2011 5:21 PM EDT |
I agree with 750: Most valuable data these days is in the user account, and not in the root account. Credit card numbers, e-mail addresses of friends / acquaintances, passwords of a gazillion websites, e-mails containing Name / Address / Residence / Bank account number, details about holidays (of great value to real-word robbers), : All of it is in the user account, exposed by potential Flash / JavaScript / Java bugs. Our friend Jim Bauwens showed me a way of 'remotely performing a simplified nmap using Javascript', if a user loads a certain website. One could elaborate that 'nmap / JS' scenario to nmap scanning which router is in use, and then from 'localhost' logging into the ADSL/Cable router found; supposing the router has default pw or the pw is stored insecure in the browser. |
| JaseP Apr 26, 2011 6:13 PM EDT |
All the more reason to not permit logins to the router except by a local machine or via WiFi. They'd have to hijack the account & execute a router login as that user. My router doesn't allow that field to store that password |
| hkwint Apr 27, 2011 3:48 AM EDT |
JaseP: When you have JS running, a JS exploit means the 'cracker' _is_ on your local machine, so limiting the login to your own local system is not going to help. A safe password not stored in the browser on the other hand may. But that's the problem: Many users don't have a strong password on their router; they use the default one thinking it's safe because only the 'local network' is allowed to login. |
| JaseP Apr 27, 2011 10:30 AM EDT |
@ hkwint: Then why aren't these exploits rampant?!?! It was my understanding that Java/JavaScript was pretty well sandboxed in most Linux distros' browsers. |
| hkwint Apr 27, 2011 11:08 AM EDT |
Sandboxed or not, the browser can interface with the webinterface of the router. Jim Bauwens was working on such an exploit, when I visited the website he pointed me to. It scanned my local network and found my router. He also had a 6-page PDF with default passwords of routers. Website is down now it seems. Probably Jim is too busy to read LXer now and respond, I don't know. |
| jimbauwens Apr 27, 2011 2:28 PM EDT |
>Probably Jim is too busy to read LXer now and respond, I don't know.
Yup, I'm to busy, as I have an exam tomorrow :) With clever javascript code it is possible to Hijack into someones router, flash a new firmware, and take over the network. Of course this takes allot of work to make, but it is possible. I myself have created a javascript application that can remote control a printer (without asking the user). It connects directly to the printer, via the lan, and can do anything to it. Print ads, print thousands of papers, display text on its display, etc.... If you are interested, my network scanning test is located at: http://bwns.be/jim/scanning_printing/detect-range.html (note that it still has some bugs). So, what I'm trying to say is, Javascript is a portway for hackers :) |
| hkwint Apr 27, 2011 5:32 PM EDT |
Ah, many thanks Jim, and great to know you're still around. Busy studying I suggest? I tried visiting the link you sent me (on webdevout), but it was gone, so I figured you were working on a new shinier version. JaseP: If you don't know Jim, he's the guy which made LXer unreachable for some time because he did some fancy Javascript stuff to the LXer servers - just for the fun of it. So you better take the guy serious, ahem; we at LXer do these days. |
| JaseP Apr 27, 2011 5:40 PM EDT |
It boggles my mind that it could be that easy to compromise a machine... Are you saying that any "script kiddie," getting a hold of this exploit could potentially take down ANY machine??? Or is this just something that can be done to a badly configured machine??? If it is that easy, why isn't this happening all over??? |
| jdixon Apr 27, 2011 7:26 PM EDT |
> Are you saying that any "script kiddie," getting a hold of this exploit could potentially take down ANY machine??? Pretty much, yes. It's a serious mistake to allow executable code from unknown sources over the Internet, and that's what javascript allows (and java, and active-x, and (as I understand it) .net, mono, and so forth). That, except possibly for the .net and mono section, is factual. The following is only a layperson's informed opinion: However, writing such code isn't that simple, and most people with the skills to do so have better things to do. Moreover, it can be stopped at any number of points along the way (yay NoScript), And people are always working to fix the bugs which allow unintended execution of such code. But it only takes one person to write the code and put it out for a zero day exploit to hit lots of people. And proper social engineering can by pass almost all of the protections. Linux isn't a monoculture, so it's relatively more immune to this than Windows, but not completely. |
| hkwint Apr 28, 2011 7:46 AM EDT |
JaseP: Taking down a machine isn't that intersting. Jim showed how he can command your printer or scan your network if you visit "his malicious" website. Could be great for the not-faint-of-heart spammers; printing adds on your printer without your consent. It's what fax-spammers do. For other security issues I have no proof, but lots of data is in your browser profile these days. That's why - as Jim told me - you should always logout from sites, and using NoScript is a good idea as well. Because why hack your root account, from there access the browsers binaries, change the browser binaries and gain access to sensitive non-privileged (local)user-data, if a cracker can access the same data directly from the browser? |
| jimbauwens Apr 28, 2011 10:09 AM EDT |
Hans wrote: Ah, many thanks Jim, and great to know you're still around. Busy studying I suggest? Yup, I have lots of work nowadays :) JaseP wrote: It boggles my mind that it could be that easy to compromise a machine... Are you saying that any "script kiddie," getting a hold of this exploit could potentially take down ANY machine??? Or is this just something that can be done to a badly configured machine??? If it is that easy, why isn't this happening all over??? Well, the code I released doesn't do that, it just scans the network, and can print to network printers. I even made a Javascript library that helps you make print jobs: http://bwns.be/jim/scanning_printing/PRINTING_README.html . Jdixon wrote: However, writing such code isn't that simple, and most people with the skills to do so have better things to do. Moreover, it can be stopped at any number of points along the way (yay NoScript), And people are always working to fix the bugs which allow unintended execution of such code. But it only takes one person to write the code and put it out for a zero day exploit to hit lots of people. And proper social engineering can by pass almost all of the protections. Linux isn't a monoculture, so it's relatively more immune to this than Windows, Very true! hans wrote: For other security issues I have no proof, but lots of data is in your browser profile these days. That's why - as Jim told me - you should always logout from sites, and using NoScript is a good idea as well. Yes, logout whenever possible! Login out disables cookies that might have been stolen by LAN sniffing, or some malicious javascript. Hans wrote: Because why hack your root account, from there access the browsers binaries, change the browser binaries and gain access to sensitive non-privileged (local)user-data, if a cracker can access the same data directly from the browser?Also very true. |
| penguinist Apr 28, 2011 11:01 AM EDT |
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. |
| jimbauwens Apr 28, 2011 2:03 PM EDT |
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. |
| hkwint Apr 28, 2011 3:07 PM EDT |
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. |
| penguinist Apr 29, 2011 9:42 PM EDT |
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. |
| jimbauwens Apr 30, 2011 5:43 AM EDT |
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. |
| JaseP May 02, 2011 9:00 AM EDT |
@ jimbauwens: All the more reason to flash your own router with custom firmware... My router is anything but stock... |
| jdixon May 02, 2011 10:17 AM EDT |
> 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. |
| jimbauwens May 02, 2011 11:24 AM EDT |
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. |
| JaseP May 02, 2011 12:28 PM EDT |
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] |
| jdixon May 02, 2011 12:49 PM EDT |
> 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. |
| jimbauwens May 02, 2011 2:56 PM EDT |
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 :) |
| JaseP May 02, 2011 5:07 PM EDT |
But Jim, you're an 18 (plus) year old with the skill set of a greybeard. Imagine one like yourself with less moral restraint... |
| jimbauwens May 03, 2011 7:02 AM EDT |
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. |
| JaseP May 03, 2011 9:09 AM EDT |
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. |
| hkwint May 04, 2011 7:38 AM EDT |
Yeah, I think a botnet of routers would do great for DDOS. |
| jimbauwens May 04, 2011 8:14 AM EDT |
Yeah, didn't think about that. |
| JaseP May 04, 2011 9:28 AM EDT |
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. |
| jimbauwens May 04, 2011 9:36 AM EDT |
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). |
| JaseP May 04, 2011 11:03 AM EDT |
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?!?! |
| jimbauwens May 04, 2011 11:27 AM EDT |
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! |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!