It's 2014 and you can still own a Windows box using a Word file or font Microsoft has today patched two dozen CVE-classified security vulnerabilities in its software. People are urged to install them as soon as possible. The US giant said the October edition of Patch Tuesday includes three critical fixes to address flaws in Internet Explorer, the .NET Framework and Windows kernel-mode driver. The …
You can stop it auto-updating with group policy. However there are - of course - no download links for the updates, nor in the Windows Update logs, or anything downloaded into whichever temp directory you can save as an installer (or not without more work than its worth).
WSUS is only useful if most of your machines fall into a few groups that can be treated identically. If you have multiple machines precisely because you need a variety of different environments for testing, then WSUS is a useless pain in the butt. It downloads far more than you will ever need and you still have to configure each machine separately.
"And in 2014 you can own a Linux box via remote shell script without user interaction - which is much worse than the above!"
Only if you have appropriate services listening on the network. All are terrible vulnerabilities; the relative severity of them depends on the use case of the system in question.
"Only if you have appropriate services listening on the network."
Like a web server for instance? - and guess what is the most common OS used by webservers is....hence presumably why Linux is also by a factor of several times the most likely to be exploited OS run on a webserver (after adjusting for market share)....
Whilst shellshock is/was a really worrying problem, I don't think that any serious web site will actually any CGI-bin bash scripts.
Yes, I know that the problem will persist across other binaries as long as they preserve the environment variables, whenever a bash is started as a child, and that the system() call will almost certainly start a shell, so there is still danger there, but I would be startled if Google, Amazon et. al. were ever vulnerable. The patching they did was mainly to be absolutely sure.
SOHO or SMB web sites may be vulnerable, of course, so I am not downgrading the risk, but I think that your implied assertion that all Linux web servers will by default be vulnerable is overstating the problem.
"Like a web server for instance? - and guess what is the most common OS used by webservers is..."
Only a relative handful of web servers (depending on configuration) were affected so remember to keep that in mind. I entirely agree that it was severe for those affected, but we've got to keep the relative numbers in mind here.
Also note that using the market share logic, Windows is by far the most common OS on the desktop, a scenario where exploiting the kernel via a font rendering bug (as an example) is pretty damn serious.
Like I said, the severity totally depends on the use case in question. Don't let that prevent you from your cherry picking your facts though.
"Linux is also by a factor of several times the most likely to be exploited OS run on a webserver (after adjusting for market share)...."
Citation needed.
Unless anything much has changed, it'll be via a blogpost from someone who turns out to be Microsoft's Director of Trusted Computing, or something like that. It's been debunked a few times, I've reposted some of the debunkings round here, and I cba looking them up right now (it's feeding time).
Oracle is now recommending Java 8 U25, and if you install it over Java 7 it helpfully offers to remove the old "insecure" version (their words on the dialog box). The only trouble is, if you say "yes", it dutifully claims to have uninstalled version 7, but has not. It's still there, and still enabled. Way to go Oracle.
It gets better. If you then do the version check using the Java website and have only 8U25 installed, it tells you that you have the latest version installed and it found no insecure versions. But guess what? If 7 is still hanging around all you get is a message saying you have the latest version installed - zero mention of the insecure version of 7 still on your machine.
Seriously, you couldn't make this stuff up.
Having the video drivers in the kernel doesn't mean the fonts have to be parsed in the kernel. That could easily be done by a non-privileged process with no performance impact - you're only going to message pass for each character you render, which might add up to a few dozen microseconds to render a screen filled with small print.
Actually although a small part of the video driver system is in the kernel, the majority of the driver runs as plug-in modules to the X server process (not kernel modules), which is a use-land process, not in the kernel. This makes graphics drivers different from, say, a driver for a disk adapter.
The bits in the kernel are to do with allowing the X server process to access the video hardware at a register/DMA level, and is pretty generic glue code. All of the smarts are in the X server, and that is the code that is most likely to have a problem. This means that it is unlikely that you can crash a Linux box with a graphics driver, although you may make it difficult to use on the directly attached monitor (other access methods are available!)
In fact, if you try hard, you don't even have to run the X server as root. Generally speaking, modern distributions do run the X server as root because it is started up before the graphical login starts, and that needs X, but if you disable the graphical login, log in as an ordinary user using a text-based authentication method, and then run up an X server (using something like startx), it works just fine.
I would actually like the graphical login methods to switch away from root during the login process. It can be done, but is likely to introduce a visible glitch as the X server restarts during the login process. But as we will end up with Wayland or Mir in the near future, changing the way that X11 is used seems a bit pointless.
In fact, if you try hard, you don't even have to run the X server as root. Generally speaking, modern distributions do run the X server as root because it is started up before the graphical login starts, and that needs X, but if you disable the graphical login, log in as an ordinary user using a text-based authentication method, and then run up an X server (using something like startx), it works just fine.
And indeed this is how most people did it, back in the day. It wasn't until X11 R4, if memory serves, that xdm became popular. (It was part of X11 R3, a contrib client written to support the "X Terminals" that were just starting to come out, but I don't recall many people using it until R4.) So for the first four years or so of X's existence people would typically log on to a conventional pty device, and then start X (often on a different display), a window manager, and some clients.
My recollection is that xdm actually could switch UID when it ran on a system.I believe that it was a configurable option, and you could specify an X server restart (partly to change the UID, but also to set the server to a known state with no client programs left over form the last user) during the login process on a device that allowed it. Obviously not on an X terminal, though.
It's later graphical login processes like gdm and lightdm that changed this.
Unfortunately I no longer have anything old enough running to confirm this.
"the video drivers are on the kernel too"
We need to stay stupid because we started off stupid.
Except, of course, they didn't. Video was outside the kernel, and called into the HAL, until NT 4. Then it was moved into the kernel to address complaints about video performance.
So it's more a case of "we started out doing it correctly, but people complained, so we decided to convert to stupid, and we'll be damned if we're going back now".
" it was moved into the kernel to address complaints about video performance."
Yep. Gates didn't like the fact that NT-based systems were slower at (some) games than Win16-based systems, that difference being due to the total lack of protection (total lack of context switches etc) in the Win16-based setups.
On the other hand, the protection provided by those separate address spaces requiring context switches etc made the NT boxes much more robust, much more stable, for general use than Win16 on the same box.
Game performance benchmarks are easy.
Real productivity benchmarks (influenced by robustness) are not so easy.
Gaming won, but businesses carried on buying anyway, they'd already been hooked, and who needs security anyway.
I was going to ask the obvious question of why the hell fonts are parsed in the kernel but someone beat me to it.
The supposed answer that the reason is that video drivers are in the kernel is no answeer at all but points to the problem, a failure of architecture and design in windows.
You do not need to go all the way to a microkernel architecture to spend some time partioning graphics and video related subsystems so that what is in the kernel is a well defined minimum. Font parsing clearly would not be in the kernel of a well designed system.
When my Linux boxen fall prey to a nasty they get trendy names and a logo (Heartbleed, Shellshock) with Windows you only get CVEs and a load of blather.
(EDIT:) My word! I glazed over the DougS comment just above here, surely a troll, and re-read the list. Sure enough, the Win kernel apparently does TTF parsing. Sorry mate and as you said: WTF.
> When my Linux boxen fall prey to a nasty they get trendy names and a logo (Heartbleed, Shellshock) with Windows you only get CVEs and a load of blather.
Remember when the National Hurricane Centre ran out of "trendy" hurricane names back in 2005 on account of there being so many storms? Yeah...
On a more serious note, I feel more and more that all OSes (both closed and open source) are pastures filled with steaming piles of cow poo. The only real differences between the two are where the piles of poo are located.
"When my Linux boxen fall prey to a nasty they get trendy names and a logo (Heartbleed, Shellshock) with Windows you only get CVEs and a load of blather."
It's easy to come up with trendy names when the need is rare - but there aren't enough hours in the day when it comes to Windows.
MS14-060 is not a flaw. It's doing exactly what it was designed to do: If an OLE object of unknown type is found, but containing a link to the viewer, then automatically download and execute the viewer. This is obviously a stupid idea, but it's also an ancient design - OLE dates all the way back to Windows 3.11 and a time when security was less of a pressing concern, so this is one of those 'seemed like a good idea at the time' things.
To the downvoter:
A relative who had worked on classified computing projects was headhunted for a technical job at Redmond during the Win 3.11 period. After three days at Redmond he turned them down, because he decided that security, compartmentalisation and the like were simply not part of their culture.
His conclusion, that Microsoft would fail, turned out to be wrong for a variety of reasons, but I was making a serious comment,not a flippant remark.
On Win7 x64: KB2952664 only installs at the second attempt; KB2949927 fails to install unless you have BitLocker running.(and hence the system has to reboot - again - to unravel this).
And on Win8.1, \Windows\system32\MRT.exe (i.e. the Malicious Software Removal Tool) gets flagged by the AVG Virus scanner.
And on Win8.1, \Windows\system32\MRT.exe (i.e. the Malicious Software Removal Tool) gets flagged by the AVG Virus scanner.
working as designed then? time for me coat then. Mines the one with an abacus in the pocket. No malware reported for them (yet...)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
