LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityForcing updatesA recent thread on the desktop-architects mailing list touched on a subject that tends to generate strong feelings: automatic, silent updates for security issues. At first blush, it is an attractive idea that might help slow down or stop a fast-moving virus or other malware. It also would help protect users who might otherwise ignore or delay updating their system. On the other hand, there are lots of concerns about whose decision it is to have a "mandatory" update, what else might be contained in such an update, as well as how to ensure that the update doesn't break the user's machine. Dan Kegel kicks off the discussion by asking:
Given how much malware is out there,
shouldn't security fixes for remotely exploitable
flaws be installed a bit more forcefully?
e.g. instead of an ignorable notification,
how about an in-your-face dialog saying
they're going to be installed now?
Or in some cases even just silently installing them?
This goes not just for distros; any ISVs is on the hook for rapid security updates these days, I would think. While there are attractions, one of the immediate downsides was noted by KDE hacker Aaron Seigo: "distro Q/A resources would have to _significantly_ increase for this to work reliably. too many updates still break too many systems on too regular a basis." The first time a silently applied "fix" breaks someone's system, there will be a serious outcry. Microsoft and others have broken people's systems before with security updates, but that doesn't seem a good example to follow. But, even with additional QA, there are plenty of reasons that a user might not want to get an update. GNOME foundation member Dave Neary presents several scenarios:
I for one would be a little paranoid about not being able to control
installs of updates. I can imagine all kinds of scenarios where it would
be undesirable: a 20M security fix starts downloading when I'm connected
via GPRS at a conference, or over a 56K phone line; a kernel update
downloads & requires a reboot; an application I am using and Absolutely
Positively Must Keep Using for a few minutes upgrades, and isn't
runtime-compatible with the update [...]
A kernel reboot or even application restart are definitely problem areas. There are many reasons a user might need to continue using a buggy application or kernel, even if the bug exposes them to an exploit. Some users have enough information to make that kind of determination, but others most definitely do not. How does the distribution or software package determine that? Presumably there will have to be settings to govern the behavior, which then begs the question: what is the default setting? An additional problem is that users are training themselves—or the desktops and distributions are training them—to ignore pop-ups of various sorts. So suggestions like the one made by Ritesh Raj Sarraf: "For updates with priority 'security', I think it should just pop-up more often" are met with skepticism. Kegel opines:
People ignore dialogs like that. IMHO if we're going to avoid
botnet nightmares, we're going to need at least some silent security
updates.
That provoked a rather boisterous response from Linus Torvalds. His argument is that you can't trust the developers of various projects to determine what fixes should be applied. He is concerned that projects might want to slip other things into a "security" release:
Yes, they may "technically" be the people with the most information, but
they are also the ones furthest removed from actual users - by definition.
And they are also the ones that are most emotionally (and often
financially) tied to things like "newest version".
His point is that he, and by extension other sophisticated users, are never going to turn over their systems to the whims of outsiders. He is willing to let distributions or even some software packages make that kind of decision, but only if things are not done silently. "There are programs that I trust to do their auto-updates, and I'm perfectly happy having firefox check for extensions automatically, for example. But even in the case of firefox, I want to _know_ when it does so." Any kind of automated, silent upgrade feature from either a particular package or a distribution would be an enormous target for those with a malicious intent. It would be a kind of dream exploit to be able to inject malware into millions of unsuspecting systems—silent and unnoticed. A break-in to a distribution server might lead to an incredible malware outbreak, though the same thing could be accomplished today; it would just take more time. But, the problem remains that there are lots of systems that are not getting updated and are thus vulnerable to a wide variety of exploits. As part of its Collaboration Summit, the Linux Foundation would like to have a meeting to discuss the issue. It is certainly an area where more thought is needed.
Brief items Rooting your own phone: android securityKernel hacker Pavel Machek is looking for kernel security holes, but perhaps not for the reason one would expect. He wants to exploit such a flaw to gain root on his Android G1 phone. He has already tried a few exploits that affect the 2.6.25 kernel, but none successfully to get root. He is looking for help from folks who may know of additional flaws to try. In his message, linked below, he also notes several security relevant issues with Android.
How to write a Linux virus in 5 easy stepsHere's a weblog posting by "foobar" describing an attack vector for desktop Linux systems. "When you save an email attachment under Linux, the execute flag is normally NOT set and thus, the file can't be executed just by clicking on it. So, no luck? Not so fast. Modern desktop environments, such as Gnome and KDE, conveniently offer a nice 'workaround' called 'launchers'. Those are small files that describe how something should be started. Just a few lines that specify the name, the icon that should be displayed and the actual command to execute. Conveniently, the syntax of those launcher files is the same for Gnome and KDE. And those launchers don't have to have any execute permissions set on them!" Your editor can't resist pointing out that this problem was covered here back in 2006. (Thanks to David Skoll).
New vulnerabilities firefox: multiple vulnerabilities
gnumeric: untrusted python modules search path
gpsdrive: multiple vulnerabilities
gstreamer-plugins: arbitrary code execution
gstreamer-plugins: heap buffer overflow
gstreamer-plugins-good: heap buffer overflows
java-1.6.0-openjdk: privilege escalation
kernel: denial of service
mod_auth_mysql: SQL injection
nss: rogue CA vulnerability
roundcubemail: cross-site scripting vulnerability
squid: denial of service
wicd: privilege escalation
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||