Severe IE 11 Bug Allows 'Persistent JavaScript' Attacks (bleepingcomputer.com)
An anonymous reader writes: New research published today shows how a malicious website owner could show a constant stream of popups, even after the user has left his site, or even worse, execute any kind of persistent JavaScript code while the user is on other domains. In an interview, the researcher who found these flaws explains that this flaw is an attacker's dream, as it could be used for: ad fraud (by continuing to load ads even when the user is navigating other sites), zero-day attacks (by downloading exploit code even after the user has left the page), tech support scams (by showing errors and popups on legitimate and reputable sites), and malvertising (by redirecting users later on, from other sites, even if they leave the malicious site too quickly).
This severe flaw in the browser security model affects only Internet Explorer 11, which unfortunately is the second most used browser version, after Chrome 55, with a market share of over 10%. Even worse for IE11 users, there's no fix available for this issue because the researcher has decided to stop reporting bugs to Microsoft after they've ignored many of his previous reports. For IE11 users, a demo page is available here.
This severe flaw in the browser security model affects only Internet Explorer 11, which unfortunately is the second most used browser version, after Chrome 55, with a market share of over 10%. Even worse for IE11 users, there's no fix available for this issue because the researcher has decided to stop reporting bugs to Microsoft after they've ignored many of his previous reports. For IE11 users, a demo page is available here.
You know it makes sense.
Mind you Google isn't that much better
Dump google
you know it makes sense.
there's no fix available for this issue because the researcher has decided to stop reporting bugs to Microsoft after they've ignored many of his previous reports.
I don't see the author saying this anywhere in Caballero's article. Maybe the reporter at the news site (and the submitter) should have read the article first.
For what it is worth, Caballero is a respected browser security researcher. I don't think he would do something like this.
1. Regular alert: Alert came up, second time. check marked it. Disappeared for ever.
2, 3, 4: htmlFile alert, all at once, in a zombie script: No effect, no popup, nothing.
Browser being tested: IE 11
no carrier
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Fairly sure this can be done other ways... Allakhazam (which has game info for many popular MMO's) auto-loads advertisements every few minutes, regardless of the users browser state.
My wife frequently walks away for 20+ minutes, only to have her computer randomly start playing an advertisement.. I suppose it isn't a "pop up", but clearly "auto refreshing for advertisement fraud" is possible and in use... And Allakhazam's method works on Firefox and Chrome from our experiences
Doesn't Chrome have the same problem? I've had to go into Task Manager and kill Chrome after getting the "You have a virus! Pay us money!" popup. (Have they fixed that in Chrome already?) My ex was stupid enough to actually call the phone number they put up on the screen, after which some Indian guy asked her for money.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
I hope the zombie script will die if the browser is killed? Or have clever people at Microsoft have implemented auto checkpoint and auto restore to make it even more persistent?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Chrome requires its sandbox process to run as root.
Chrome runs under the user id it was started from. No idea what you want to claim.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Yes... other languages "could" have the same problem, and it's not the language per se that's the issue, but javscript is in the position where it's loaded from random malicious or semimalicious web sites and executed in your browser.
If you let that happen by default, after an endless fucking series of javascript based exploits and vulnerabilities and nagware and data-harvesting over the years.. at this point I no longer feel sorry for you. You're letting random strangers who do not mean you well control the operation of a not-well sandboxed environment on your computer, so you deserve what you get.
Running with javascript default-enabled is like letting any stranger in the world use your house for any purpose they want. Might be the an organization who saves orphan cancer victims from bear attacks, or might be drug cartels and human trafficking, or the Stasi planting recording devices. You're saying, "Hey, it's all good! Come on in, do what you want!"
I wager almost nobody would do that with their house, but somehow with computers people have decided that's a good plan. Then they wonder why they suffer from the endless series of problems they do.
"new ActiveXObject('Microsoft.Ancient.Bad.Idea')" I think I've seen this exploit before. SMH. It's time to kill ActiveX in the browser already.
If this issue were a problem in Javascript it (or some variant) would work in a lot more browsers than just IE11.
But it's not. The bug here boils down to Microsoft adding an ActiveX call into Javascript, then that call activating some native HTML ActiveX component and using it in a super bad way.
That's not Javascript's fault, that's on Microsoft for punching such a large hole in the sandbox.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If any outsider can install and run a program on your computer it is no longer your computer. Javascript is such a program. So is the permission to open a Microsoft docx document. In a corporate environment there is usually a guard dog to protect you. In a home Windows, Apple or Unix-based system you are on your own. If you leave the keys to your car in the ignition don't be surprised if someone takes it for a ride.
Make your own decision.
That way we can track you with an advertiser ID in a feeble way to sell apps on the appstore and actual think this will get people to buy Windows Phone?
Why fix it? This is great scareware to get PHB IT managers to upgrade and leave perfectly working 7 behind.
http://saveie6.com/
Unfortunately, IE is far from dead and is mandated by many corporate users and is used by Grandma.
MS needs to secure it as long as it's part of 8/10. Yes IE 11 is part of 10 in addition to edge if you look for it. Corporations use a GPO to put IE 11 over edge at work
http://saveie6.com/
What the fuck are you talking about? Nothing in Chrome requires a root user.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Linux setuid sandbox allows local privilege escalation
So the chrome_sandbox binary being owned by root and having the setuid bit set is an "extraordinary claim" is it snowflake? No, its a fact. I don't need to cite anything. 5 seconds with google will tell you everything you need to know and if you're too bone idle to bother then thats your problem, not mine.
You're not supposed to drink espresso like it was cappuccino. But if you want to make claims and then not support them at the same time as you call anyone who disagrees with you morons, well, I think you might be better suited for Youtube comments. Edumacate peeps.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Thanks for proving my point in my original post about ignorant fools with no clue about security.
Newsflash: claims only need supporting if there's no way for 3rd parties to independently verify them. But here, especially for dumb special needs kids like you who can't use a search engine:
http://lmgtfy.com/?q=chrome_sa...
Chrome runs under the user id it was started from.
... and then proceeds by invoking a set-uid binary (that it conveniently set up at installation time) to become root:
# ls -ld /usr/lib/chromium/chrome-sandbox /usr/lib/chromium/chrome-sandbox
-rwsr-xr-x 1 root root 14664 Jan 30 18:39
Quite. The fact that there are so many idiots on here who not only didn't know this but didn't know how to find out is quite staggering. Ubuntu has a lot to answer for IMO.
Nothing in Chrome requires a root user.
Unfortunately, it does, I didn't believe it myself at first...: /usr/lib/chromium/chrome-sandbox /usr/lib/chromium/chrome-sandbox
# ls -l
-rwsr-xr-x 1 root root 14664 Jan 30 18:39
Removing that s bit causes chromium to refuse to run: /usr/lib/chromium/chrome-sandbox is owned by root and has mode 4755.
> chromium
[28193:28193:0225/213608.315538:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that
#0 0x564a04ba083e <unknown>
#1 0x564a04bb4f7b <unknown>
#2 0x564a05a0f4cf <unknown>
#3 0x564a043f3def <unknown>
#4 0x564a043f325e <unknown>
#5 0x564a043f384e <unknown>
#6 0x564a0408872c <unknown>
#7 0x564a0409036d <unknown>
#8 0x564a04087dcc <unknown>
#9 0x564a0480764b <unknown>
#10 0x564a04805fa0 <unknown>
#11 0x564a033de1bc ChromeMain
#12 0x7ff5074f5b45 __libc_start_main
#13 0x564a033de069
zsh: abort chromium
Thanks for proving my point in my original post about ignorant fools with no clue about security.
Oh do go on. I feed on your ranting.
Newsflash: claims only need supporting if there's no way for 3rd parties to independently verify them. But here, especially for dumb special needs kids like you who can't use a search engine:
http://lmgtfy.com/?q=chrome_sa...
Okay, it has been proven conclusively. You, our good Viol8, could have chosen to be anything you want, and for some reason you chose to be an asshole.
Because in the end, it doesn't matter whether you are right or wrong.
But please, do rant on. It's most entertaining, and might even do you some good to release all that pent up anger. Thanks for the Lulz.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
It silently self-escalates when it runs. Did you think Chrome wasn't a root kit? It's a browser built by an advertising company, why would you expect it to behave differently than weatherbug?
Socialism: a lie told by totalitarians and believed by fools.
Son of the gun. Verified on my system (under /opt/google/chrome).
Didn't know that. Kind of glad I switched to Vivaldi for most things.
Glad you pointed this out.
To avoid the security issue of chrome on linux, I suggest you switch to internet explorer. I haven't heard of any exploits of internet explorer on linux yet.
Yeah, about that... You might want to take a look at /opt/vivaldi/vivaldi-sandbox, then.
Running with javascript default-enabled is like letting any stranger in the world use your house for any purpose they want.
If most people change the default to no JS, what steps should a developer of a web application take to convince prospective users that the web application is legitimate? Or should all applications instead be native and therefore specific to a single operating system?
Java and Javascript are not the same thing.
I think Joe Branya would recommend turning them both off, as well as Flash and Silverlight.
Yes, just discovered that too (about Vivaldi).... not pleasant at all.
What's left? Firefox? Save me from that... maybe Pale Moon is worth another look.
Internet Explorer 11 requires Windows 7 SP1 for higher. Microsoft would be quick to point out that that have offered free upgrades to Windows 10, featuring their new, more secure Edge browser, for over a year now.
> Removing that s bit causes chromium to refuse to run:
ENOREPRO
ls -ld /usr/lib/chromium-browser/chromium-browser /usr/lib/chromium-browser/chromium-browser /usr/lib/chromium-browser/chrome-sandbox /usr/lib/chromium-browser/chrome-sandbox
-rwxr-xr-x 1 root root 46008184 Dec 17 09:05
$ ls -ld
-r-xr-xr-x 1 root root 14296 Dec 17 09:05
$ lsb_release -irc
Distributor ID: Ubuntu
Release: 16.10
Codename: yakkety
$ apt search chromium-browser
Sorting... Done
Full Text Search... Done
chromium-browser/yakkety-security,yakkety-updates,now 55.0.2883.87-0ubuntu1.16.10.1330 amd64 [installed]
Chromium web browser, open-source version of Chrome
chromium-browser-l10n/yakkety-security,yakkety-security,yakkety-updates,yakkety-updates,now 55.0.2883.87-0ubuntu1.16.10.1330 all [installed,automatic]
chromium-browser language packages
about://sandbox reports:
Sandbox Status
SUID Sandbox No
Namespace Sandbox Yes
PID namespaces Yes
Network namespaces Yes
Seccomp-BPF sandbox Yes
Seccomp-BPF sandbox supports TSYNC Yes
Yama LSM enforcing Yes
You are adequately sandboxed.
Mods, mod me up to +5, Insightful, too.
Chrome runs under the user id it was started from.
... and then proceeds by invoking a set-uid binary (that it conveniently set up at installation time) to become root:
# ls -ld /usr/lib/chromium/chrome-sandbox
-rwsr-xr-x 1 root root 14664 Jan 30 18:39 /usr/lib/chromium/chrome-sandbox
On my machine (Fedora 25): /usr/lib/chromium/chrome-sandbox
> ls -ld
ls: cannot access '/usr/lib/chromium/chrome-sandbox': No such file or directory
I do run Chrome, Firefox, Konqueror and QupZilla. I can run any browser I want except IE unless I am stupid enough to run a virtual machine with Microsoft Windows although to be fair Windows 10 does not run IE but it only pays attention to the "hosts" file when it suits itself to do so.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
This is why everyone should be running Noscript. Javascript is a major security risk and should only be run on sites you completely trust 100%. Even then it is the most likely vector for viruses and malware.
Quite an experience to live in fear, isn't it? That's what it is to be a slave.
Ubuntu has a lot to answer for IMO.
Actually, this is a Debian system where I saw this... And one Anonymous Coward claims that on his Ubuntu 16.10 system, Chromium doesn't have the bug. So let's be careful who deserves the blame here... my hunch is that it's google itself, rather than the distro.
On my machine (Fedora 25): /usr/lib/chromium/chrome-sandbox
> ls -ld
ls: cannot access '/usr/lib/chromium/chrome-sandbox': No such file or directory
Careful there, the offending binary might just be called something else (chrome instead of chromium, in /usr/local/lib instead of /usr/lib), etc.
Just try locate sandbox, or rpm -q -l chromium | xargs ls -ld | egrep '^-..s' to be sure...
$ ls -ld /bin/ping /bin/ping
-rwsr-xr-x 1 root root 60288 Jun 15 2016
Not on my Debian:
> ls -ld /bin/ping /bin/ping
-rwxr-xr-x 1 root root 44104 Nov 8 2014
You're talking about using software that has access to your keystrokes, mouse movements and clicks,
Only its own (although I wouldn't trust most distros' X setups to appropriately protect applications from each other in that regard, but that's another peeve...).
the plaintext of your TLS sessions.
Again, only their own. As long as I use Firefox for the serious stuff, and chromium only for browsing Javascript infested thrashcan sites my TLS sessions (from Firefox) would still be safe. But with this bug... not so sure.
It also controls the layout and placement of the content that it's presented. The majority of PC-using Americans do pretty much everything in their web browsers.
This is not about the computers of the trump voters (these would use IE 11 on Windows anyways...), but about the computers of more tech-savvy users who just wouldn't expect something like this.
If Google were malicious, they'd be able to get all the data they'd ever want without ever touching root privs.
Not malicious, just callous. Rechklessly allowing third parties (shady sites packed full of Javascripts) to leverage that hole to get admin on victim's computer.
the researcher has decided to stop reporting bugs to Microsoft after they've ignored many of his previous reports
Yeah, I can empathise... MS have some really shitty strategies for dealing with bug reports, although I don't post security bugs my experience is:
I know that closed source has less resources but a) don't be fucking closed source then and b) don't use underhanded techniques to reduce your bug count because it will just piss everyone off.
I guess that is more a problem of the installation process than any 'necessity' ... if you know that, why don't you remove the s bit?
And how can it be that the user and groop is root anyway? I guess you installed Chrome as root, so the mistake is just yours.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I guess that is more a problem of the installation process than any 'necessity' ... if you know that, why don't you remove the s bit?
Have you stopped beating your wife? :-)
Well, as stated in my other message, if I remove the s bit Chromium will refuse to start.
And how can it be that the user and groop is root anyway?
Most software belongs to root... (have you actually ever looked at any software on your own system, or are you just trolling?)
I guess you installed Chrome as root
In this case, I trusted my distribution, and installed the .deb from repository.
so the mistake is just yours.
If I had installed it manually in my own directory, chances are, it would refuse to run (... as it would not be setuid root)
The software belongs to the one who is installing it.
And that is in 99& of the cases: not 'root'.
There is a reason why you have /usr/bin ...
And we where talking about Chrome, not Chromium, or do I miss anything?
Anyway: I'm on a mac and don't "install" software. I drag&drop it from the installation medium to my Applications folder: hence it has no S bit, is running with my rights and not with anyone else rights.
Sorry, if that applications needs s-bit as root to run: delete it.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
And we where talking about Chrome, not Chromium, or do I miss anything?
In my case it's Chromium (hence nicely packaged as a .deb), but the original poster observed the same thing about Chrome. That it also happens with Chromium on some distributions is worrisome: Chromium is supposed to be repackaged, so that the distributor can remove such shenanigans. Ubuntu managed to do that (in 16.10). Debian, unfortunately, didn't.
Sorry, if that applications needs s-bit as root to run: delete it.
Which is what ended up doing...
And I would have done it much earlier had I known (suspected) this. And in order give other people, who might still be as unsuspecting as I am, a heads up, I'm talking about it.
It will probably work if started with the "--no-sandbox" option (that's what I use with a "bleeding edge" chrome I've downloaded and installed as a regular user)
I usually run browsers as a separate user that is allowed onto the X11 server via xauth (this is more out of ritual cleanliness than security -- browsers leave around much dotfile spam and they also love to start a lot of dubious garbage I don't like, like pulseaudio and dbus).
> Not on my Debian:
I thought you were using Ubuntu a minute ago. What happened?
To you and the equally clueless AC:
> Rechklessly (sic) allowing third parties (shady sites packed full of Javascripts) to leverage that hole to get admin on victim's computer.
and:
> WHEN someone else takes advantage of a Chrome zero day, they'll get root permission instead of limited to user permissions.
$ chromium-browser &> /dev/null & /dev/null &
[1] 7723
$ google-chrome &>
[2] 8007
$ pgrep sandbox | wc -l
0
$
chromium-sandbox runs, does its work, and terminates. It's not a daemon.
Maybe my google-fu is weak, but I haven't found any evidence of a Chrome sandbox fault that grants you root privs. Believe it or not, if you're careful, it's not difficult to write code that runs as setuid root and drops privs looooooong before you do anything other than call privileged system setup code. (And the Chrome security guys are nothing if not careful.)
We don't freak out about the fact that Apache starts at root and pivots to another user, because it does just what's required and setuid's to some less privved user. Given its track record, the only real reason to freak out about Chrome's sandbox executable is to spread anti-Google FUD.
Here's the bulk of the code for the setuid Chrome sandbox:
https://chromium.googlesource.com/chromium/chromium/+/master/sandbox/linux/suid/sandbox.c
lemmy know if you see anything concerning. Make careful note of the inputs for each function, and which of those inputs are user-controlled, rather than controlled by the sandbox process.
> >You're talking about using software that has access to your keystrokes, mouse movements and clicks,
> Only its own...
Unless you've gone to the trouble to run each X11 client in its own server (and are doing some sort of forwarding from that server to a master server), then _all_ X11 clients have access to keystrokes and (I'm pretty sure) mouse movements. (And I'm not entirely sure that that would work as desired.) Things like pinentry make a valiant attempt to prevent this, but they fail against an even vaguely determined attacker.
Perhaps time to put every application into its own VM, sigh.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.