Facebook may be evil, but I don't understand why we blame Facebook for this "exploit".
The user grants Website X permission to use their Facebook data. Website X obtains that data. Website X subsequently runs a malicious script on their own website which harvests that data.
EXACTLY. The summary is horrible. It made it sound like Google invented a novel technique that makes the KPTI/Variant 3 (Meltdown) mitigation slowdown "negligible". But actually the blog post simply says:
They invented a technique called Retpoline that mitigates Variant 2, with negligible performance impact; and
When testing KPTI/Variant 3 (Meltdown) mitigation on their own workflows, they found the performance impact negligible.
FTP pretty much died as mainstream when NAT routers became ubiquitous. Switching from active (PORT) to passive (PASV) ftp on the client side only worked until the FTP servers themselves were also behind a NAT.
If both sides are behind a NAT, HTTP wouldn't work either (without the serious reconfiguration they you mentioned), no?
Nah, not that. The lock screen asks for the passcode. This article is about the Apple ID password. (Again, I can't confirm how exactly it works - maybe it only asks for that when you use iCloud)
From what I've read (can't confirm since I don't use iOS), the system sometimes asks for your password even if you use TouchID for authentication. If so, there's the flaw.
You can't really compare this to desktop OSes like Windows or Mac OS.
The security model there is different. All "apps" you run on them are implicitly trusted; there is no security barrier between apps.
You don't need to fake a Gmail login prompt on Windows because you can simply read the memory of the browser or Gmail app and it will gladly give the memory contents including the password to you (if it still has it).
In iOS, each app is supposed to be isolated from each other and from the OS so this is a big(ger) deal.
If your browser would let any web site show https://myaccount.google.com/ in the address bar with the green padlock, is that not a security flaw?
Not saying this is exactly the same, but if a platform makes it very hard or impossible for the user to detect a phishing attack, it is a security flaw.
When the break-in first came to light, lots of people criticized Equifax, but a vocal minority said something along the lines of "No system is absolutely secure. We don't know if the hackers used a zero-day vulnerability against Equifax. They could have followed all the security best practices and still be hacked."
My response was "If the past is any guide, every time a major company was hacked, it was eventually traced to vulnerabilities in outdated software that should have been patched months ago. I am going to assume this is the same."
I fail to see how DNSSEC is the solution.
You'll be going from trusting a bunch of different CAs, to trusting a single domain name registry for your security.
Yes, the current CA system is bad, but having a single point of failure is even worse IMO.
I believe it was an error. Although HTC does deserve part of the blame.
You see, the "stock keyboard" was actually a third-party app, which is ad-supported by default.
The HTC version is supposed to be a special ad-free version, but somehow during the latest update the app developers pushed the ad-supported version to HTC devices as well.
If anything, this demonstrates the dangers of bundling apps that you don't directly control.
And who's to say the ad-free version doesn't still track the user or collect personal information? If it wants it could collect all your passwords too!
It was really poor judgement on HTC's part to use such an app for a sensitive component like the stock keyboard.
As much as I don't trust Google, at least Chrome is (mostly) open source.
Opera is not open source except for the third-party open source components that they used and modified.
And given that it was adware not too long ago, I simply can't trust it.
I need to trust my browser.
You might want to read up on what "privilege escalation" means...
none of those applications have sufficient rights to change the/etc/sudoer file
None of these applications should be able to change sudoers, but due to this bug all of them are actually able to. That is why it is called privilege escalation.
Most unix admins don't allow anyone root access
That is exactly why this is a vulnerability. If the users already have root access, there will be no privilege escalation and this wouldn't be a vulnerability at all...
The bug has only been observed in the wild in an installer, but that doesn't mean it can only be exploited by an installer.
If you read the proof-of-concept in the OP link, no installer was involved at all.
More generally, I don't understand why you seem to think a non-privileged (i.e. not running as root) installer process could exploit this bug in a way that a browser process cannot.
Remember, we are discussing the hypothetical scenario of your browser already executing attacker-controlled code (through some other code execution exploit).
My technical analysis:
The bug lies in the dynamic linker (dyld) failing to close the log file descriptor before executing the (possibly setuid) program.
And the log file that it uses can be controlled by an environmental variable.
So if you can make any setuid program execute some other program of your choice (this is easy and usually legitimate, e.g. crontab running your editor), you can make dyld open any file as root, and your program will eventually inherit the file descriptor.
You can then use the file descriptor to write to that file that you can't normally write to.
At this point, of course, it is easy to gain root privileges by writing to any of a number of sensitive files. (The installer exploit used sudoers, but the POC overwrote other setuid programs instead.)
Sometimes I wonder if Mac users have been living in a world without malware for too long, they can't seem to grasp security concepts that other users encounter every day...
In China, local antivirus software vendors have a reputation of being shady, often bundling questionable software and forcibly removing their competitors' software (imagine that!). I heard the "international" versions are less aggressive, but personally I still wouldn't let any of them near any of my computers. This is the first time I heard someone outside China using those.
I can never understand why people use or even buy antivirus software from not-so-trustworthy vendors when Microsoft offers one for free that is fast and effective.
OK, that's actually a reasonable explanation.
Though it would have been more believable (and prevented some angry comments in this thread) if you wrote this in the summary.
they've been doing stuff like this since 2013. I remember telling it to everyone back then, but was only met with dismissal. Why is everyone so outraged now?
Because back then they were doing it only for projects whose maintainers consented to it. (as a kind of twisted revenue-sharing program)
Now they are hijacking the installers of so-called "abandoned" projects, and locking out the owners too.
2) I call bullshit on SourceForge's assertion that their adware only comes with projects that aren't actively maintained. There have been a lot of complaints about FileZilla downloads
This is news because Sourceforge used to be trustworthy.
It used to be a respected site where open-source developers could host their binaries without fear of someone tampering with it.
Slashdot Mirror
Facebook may be evil, but I don't understand why we blame Facebook for this "exploit".
The user grants Website X permission to use their Facebook data. Website X obtains that data. Website X subsequently runs a malicious script on their own website which harvests that data.
Wouldn't this be, like, the fault of Website X?
EXACTLY. The summary is horrible. It made it sound like Google invented a novel technique that makes the KPTI/Variant 3 (Meltdown) mitigation slowdown "negligible". But actually the blog post simply says:
FTP pretty much died as mainstream when NAT routers became ubiquitous. Switching from active (PORT) to passive (PASV) ftp on the client side only worked until the FTP servers themselves were also behind a NAT.
If both sides are behind a NAT, HTTP wouldn't work either (without the serious reconfiguration they you mentioned), no?
I'm curious, how would you deploy code in other languages that also depend on external modules/packages?
Nah, not that. The lock screen asks for the passcode. This article is about the Apple ID password. (Again, I can't confirm how exactly it works - maybe it only asks for that when you use iCloud)
From what I've read (can't confirm since I don't use iOS), the system sometimes asks for your password even if you use TouchID for authentication. If so, there's the flaw.
You can't really compare this to desktop OSes like Windows or Mac OS.
The security model there is different. All "apps" you run on them are implicitly trusted; there is no security barrier between apps.
You don't need to fake a Gmail login prompt on Windows because you can simply read the memory of the browser or Gmail app and it will gladly give the memory contents including the password to you (if it still has it).
In iOS, each app is supposed to be isolated from each other and from the OS so this is a big(ger) deal.
If your browser would let any web site show https://myaccount.google.com/ in the address bar with the green padlock, is that not a security flaw?
Not saying this is exactly the same, but if a platform makes it very hard or impossible for the user to detect a phishing attack, it is a security flaw.
When the break-in first came to light, lots of people criticized Equifax, but a vocal minority said something along the lines of "No system is absolutely secure. We don't know if the hackers used a zero-day vulnerability against Equifax. They could have followed all the security best practices and still be hacked."
My response was "If the past is any guide, every time a major company was hacked, it was eventually traced to vulnerabilities in outdated software that should have been patched months ago. I am going to assume this is the same."
Turns out I was right. Companies never learn.
I fail to see how DNSSEC is the solution.
You'll be going from trusting a bunch of different CAs, to trusting a single domain name registry for your security.
Yes, the current CA system is bad, but having a single point of failure is even worse IMO.
I believe it was an error. Although HTC does deserve part of the blame.
You see, the "stock keyboard" was actually a third-party app, which is ad-supported by default.
The HTC version is supposed to be a special ad-free version, but somehow during the latest update the app developers pushed the ad-supported version to HTC devices as well.
If anything, this demonstrates the dangers of bundling apps that you don't directly control.
And who's to say the ad-free version doesn't still track the user or collect personal information? If it wants it could collect all your passwords too!
It was really poor judgement on HTC's part to use such an app for a sensitive component like the stock keyboard.
Google works fine for me on Firefox.
You really should check if you are being MITM'ed.
As much as I don't trust Google, at least Chrome is (mostly) open source.
Opera is not open source except for the third-party open source components that they used and modified.
And given that it was adware not too long ago, I simply can't trust it.
I need to trust my browser.
Is subscriptions still available? They seem to have removed the subscriptions link from the front page.
Mod points are not only given to users with excellent karma.
In fact, I got from "Normal" to "Good" karma just by moderating.
Dell Precision M4400 in 2012, I, naturally went to download the service manual for it, and found there was no such thing anymore..
You mean this?
http://downloads.dell.com/Manuals/all-products/esuprt_laptop/esuprt_precision_mobile/precision-m4400_Service%20Manual_en-us.pdf
Sure it looks like it was badly converted from a web page, but it is usable.
As far as I can tell, the newest models have service manuals too (sometimes called "Owner's Manual").
You might want to read up on what "privilege escalation" means...
none of those applications have sufficient rights to change the /etc/sudoer file
None of these applications should be able to change sudoers, but due to this bug all of them are actually able to. That is why it is called privilege escalation.
Most unix admins don't allow anyone root access
That is exactly why this is a vulnerability. If the users already have root access, there will be no privilege escalation and this wouldn't be a vulnerability at all...
No, no, no...
The bug has only been observed in the wild in an installer, but that doesn't mean it can only be exploited by an installer.
If you read the proof-of-concept in the OP link, no installer was involved at all.
More generally, I don't understand why you seem to think a non-privileged (i.e. not running as root) installer process could exploit this bug in a way that a browser process cannot.
Remember, we are discussing the hypothetical scenario of your browser already executing attacker-controlled code (through some other code execution exploit).
My technical analysis:
The bug lies in the dynamic linker (dyld) failing to close the log file descriptor before executing the (possibly setuid) program.
And the log file that it uses can be controlled by an environmental variable.
So if you can make any setuid program execute some other program of your choice (this is easy and usually legitimate, e.g. crontab running your editor), you can make dyld open any file as root, and your program will eventually inherit the file descriptor.
You can then use the file descriptor to write to that file that you can't normally write to.
At this point, of course, it is easy to gain root privileges by writing to any of a number of sensitive files. (The installer exploit used sudoers, but the POC overwrote other setuid programs instead.)
Sometimes I wonder if Mac users have been living in a world without malware for too long, they can't seem to grasp security concepts that other users encounter every day...
What? This is the Chinese antivirus vendor that was caught cheating in antivirus tests not long ago.
In China, local antivirus software vendors have a reputation of being shady, often bundling questionable software and forcibly removing their competitors' software (imagine that!). I heard the "international" versions are less aggressive, but personally I still wouldn't let any of them near any of my computers. This is the first time I heard someone outside China using those.
I can never understand why people use or even buy antivirus software from not-so-trustworthy vendors when Microsoft offers one for free that is fast and effective.
OK, that's actually a reasonable explanation.
Though it would have been more believable (and prevented some angry comments in this thread) if you wrote this in the summary.
they've been doing stuff like this since 2013. I remember telling it to everyone back then, but was only met with dismissal. Why is everyone so outraged now?
Because back then they were doing it only for projects whose maintainers consented to it. (as a kind of twisted revenue-sharing program)
Now they are hijacking the installers of so-called "abandoned" projects, and locking out the owners too.
2) I call bullshit on SourceForge's assertion that their adware only comes with projects that aren't actively maintained. There have been a lot of complaints about FileZilla downloads
FileZilla developers actually opted-in to this though.
That is not the case with GIMP.
For the record, the FileZilla developers actually opted-in to this, several years ago, in some kind of revenue-sharing program with Sourceforge.
What is new is that SF now does it with "abandoned" projects without the owners' consent too.
This is news because Sourceforge used to be trustworthy.
It used to be a respected site where open-source developers could host their binaries without fear of someone tampering with it.
I don't buy the /. editors' explanation.
This story has been repeatedly submitted since at least late Wednesday and has been voted to red multiple times in the firehose.
Meanwhile, most other red stories have already appeared on the front page, so clearly some editors were still around...