Ubuntu Core Snaps door shut on Linux's new Dirty COWs Canonical has released Ubuntu Core 16 for IoT, featuring Linux self-patching for a generation of users against future Bash or Dirty COWs. Ubuntu Core 16 features Snaps, a zip file concept Canonical says will streamline IoT device updates protecting against hackers and data loss. Snaps shipped in Ubuntu 16.10 but Ubuntu Core is …
Yep the real question is when did Red Hat become the next Microsoft. Sadly Gnome 3, udev, and systemd, did a lot to show these days most new Linux centric userland is Red Hat. With kdbus they were even looking largely to bypassing the GPL in kernel land but thankfully it looks like that one might have been a bridge too far even for them.
Yep the real question is when did Red Hat become the next Microsoft.
i.e. An NSA sympathetic turbid kludge pusher?
>Years after the COW bug was introduced into the kernel.
Certainly other UNIX kernels more mission critical imho (though granted all complex code has bugs but having pretty much largely the same code base for a long period of time) but since Linux is now "good enough" (Linux should trademark that term) expect more.
There does appear to be a problem with basic innumeracy here, since a handful of Linux kernel bugs scarcely comes close to the sum of all Windows bugs over the same period. However, a bug is a bug and you only need one to hack a system.
Perhaps the real way in which Linux systems are becoming like their Windows cousins is that bugs are remaining unpatched because the vendor can't be arsed and they are the only ones who can do it. I'm thinking here of vulnerabilities in IoT devices, or old routers for which the vendor hasn't issued a firmware patch in years, or phones where they'd much rather you pay to upgrade than they pay to maintain their product line for more than 12 months.
But desktop Linux, where just about any distro you care to name is regularly patched and the applications tend not to regard "executable third-party data" as a feature? ... these remain pretty damn safe to use.
I've seen that as an issue on windows and linux. Your third party vend picks up their tools and leave. Now what. Lets say it's open source. Now you can hire some to work it. Problem is they find out the last two versions were shit and have to start from beginning. At that point you are not commissioning a rewrite but writing the program from the ground up. Now do you fix it, hire some to write custom software which over the years get fucked up or do you move on to a new program.
> They [ snaps from Canonical ] contain code from the Linux kernel maker, Canonical for the Ubuntu distro, and the device maker and ISVs whose code might be resident onboard
All very well: pushing updates to IoT systems even though they don't ask for them. However, this leaves Canonical as the self-appointed guardian of the IoT-verse. Will they accept the responsibility of "snapping" every Ubuntu based IoT device from now to eternity? Will they only provide snaps for a specific length of time - say: for LTS kernels' lifespan or for "blessed" (paid for, subscription, rented ?) devices. And if so, what happens after that? do the devices merely become unsupported and therefore just as vulnerable as they are now - or does Canonical or the device-maker decide to brick them, in the interests of everyone else's security from bot-nets?
Finally, Canonical won't be around forever. who takes the strain when they exit(0)?
This sounds like a nice feature, but the implications need to be made clear.
-- the Guardian of the Universe?
I don't think that's how Snaps work. If I read correctly with these coke-bottle glasses of mine, then the application devs are responsible for maintaining their product's Snap. For example, Firefox will maintain the Snap for it's software:
"'We strive to offer users a great experience and make Firefox available across many platforms, devices and operating systems. With the introduction of snaps, continually optimizing Firefox will become possible, providing Linux users the most up-to-date features,' said Nick Nguyen, Vice President of Product, Firefox at Mozilla." (Linky)
The question is not whether Canonical will be a proper gatekeeper, but rather will the devs responsible for your IoT router issue new Snaps in a timely manner? I would decline to hold my breath on that. Given current vendor dysfunction, a router may indeed become a "rooter" in the Australian sense -- with or without Snaps.
> Linux has always been vulnerable. Just not as exploited
True, but Windows has been exploitable _by_design_.
Everything from port 139 being open by default, through executing programs on a CD or USB being run when inserted, downloaded programs being executable without any further action, merely selecting an email executes code, the list goes on of all these 'convenience' features designed into the system. Many have been closed, or at least give warnings, but Linux made far fewer mistakes of these types.
"True, but Windows has been exploitable _by_design_"
Although ... it is interesting to note that the people who designed windows NT were mostly luminaries from previous OS projects much lauded in these hallowed halls.
"Many have been closed, or at least give warnings, but Linux made far fewer mistakes of these types."
Would it be too jejune to point out that Windows was deploying into the heady universe of a new World Wide Web a-borning*, and that Linux has had the advantage of walking behind and seeing where the biggest landmines were?
* Indeed, was a big part of wedding computers to the idea of the never finished software requiring a persistent internet connection from the get-go. I only got my first AOL account so I could download the drivers that would make third party software do what it promised on the side of the box I bought it in, a sad process that has bloomed into a Standard Business Model.
"the people who designed windows NT"
To be fair, NT was under the control of Engineering until Marketing started getting their evil little claws into it with the release of NT5.0 (Win2K) ... By the time NT5.1 (WinXP) came out, Engineering no longer had any say in the matter. The rest, as they say, is history.
"Would it be too jejune to point out that Windows was deploying into the heady universe of a new World Wide Web a-borning*, and that Linux has had the advantage of walking behind and seeing where the biggest landmines were?"
Could you clarify this? Are you really saying that Microsoft had a head-start on Linux WRT "The Web", and thus Linux had the advantage of learning from Microsoft's mistakes? If so, do you know how silly you sound, and why?
Really? Are *you* saying that *none* of the experiential lessons learned by watching how people behaved in the (Windows dominated) Wild Wild Web informed any of the Linux design decisions taken over the years, or had any bearing of how default distrinbutions self-configure out-of-the-box? Ubuntu owes *nothing* of it's hardening considerations to stuff happening in the real world? Debian was put together by people with earplugs who sang "LALALA" as they worked?
Because if you are, well, you know how you sound.
We can see what happens when a Linux-based system is configured and released into the wild by people who don't pay attention simply by looking at the news from last week: so many webcams, so many thermostats, so many DDOS bots. The bad actor world is partying like it was Windows 95 all over again.
> Really? Are *you* saying that *none* of the experiential lessons learned by watching how people behaved in the (Windows dominated) Wild Wild Web informed any of the Linux design decisions taken over the years,
The WWW browser end is now dominated by mobile, and nearly 90% of that is Linux based.
https://www.theguardian.com/technology/2016/nov/02/mobile-web-browsing-desktop-smartphones-tablets
The WWW server market has been dominated by Unix and Linux for many years*.
Sure, the Linux developers watched Microsoft make mistake after mistake, but as they already had their designs in place, without these 'mis-features', there was nothing to actually learn from Microsoft. Linux didn't need to learn from Windows to not execute Javascript or Office macros in email by merely selecting the email, they already knew that was stupid before Windows did it. They already knew that disguising 'tennisknickers.jpeg.exe' in an email as 'tennisknickers.jpeg' and running that program when the user clicked on it was not a good idea.
* Microsoft did raise their share by domains by paying server farms to put all their parked domains on Windows servers. This shows that Windows servers are the first choice for domains that have no content and no visitors.
Stevie, I don't think you are properly equipped for this conversation, at least not from an historical perspective.
Consider for a start that Microsoft didn't even have a dog in TehIntraWebTubes race untill Win3.11 "For Workgroups". And even then, their product shipped with the TCP/IP stack lifted straight from BSD. As were a bunch of userland tools (ftp, telnet, traceroute, et alia). And even then, the Internet tools shipped as an add-on package called "Wolverine" in August of 1994, nearly a year after WfW 3.11 itself shipped.
Those of us actually developing in ^nix land seldom even thought about Redmond's offerings, much less borrowed from their lack of progress. Why not? I'm glad you asked. We didn't care because Microsoft didn't even have an actual Operating System aimed at the home user until 2001, with the introduction of WinXP. Prior to that, all MS "for home users" products were simple brain-dead program loaders. Nobody in their right mind would put such an insecure package online with any great regularity, right?
The Johnny-come-lately companies "leveraging Linux" are band wagon jumpers. To date I have seen little from them that actually is useful in my day-to-day life. From my perspective, they seem to be more interested in the corporate bottom line than actually understanding and helping the FOSS world. But that's OK, the FOSS world is already seeing them as damage & routing around them. Except in the corporate world ... and the corporate world will get exactly what it asks for. Crying shame it didn't pause long enough first to parse the problem and THEN ask the question ...
Ubuntu -- An ancient African word meaning "Slackware is HARD!"
"We can see what happens when a Linux-based system is configured and released into the wild by people who don't pay attention simply by looking at the news from last week: so many webcams, so many thermostats, so many DDOS bots. The bad actor world is partying like it was Windows 95 all over again."
THIS, on the other hand, is an entirely different kettle of worms. Can't blame a tool if it is improperly deployed.
> Would it be too jejune to point out that Windows was deploying into the heady universe of a new World Wide Web a-borning*,
That is just bullshit. Microsoft was late getting into the Internet. The first edition of 'The Road Ahead' made no mention of the internet. When the initial retail Windows 95 came out it did not connect to the internet* but instead only connected to the original MSN, a private network for Win95 only. At that time OS/2 and Unix were far ahead in _running_ the WWW.
> and that Linux has had the advantage of walking behind and seeing where the biggest landmines were?
Linux didn't do stuff (or not do it) because Windows showed it was wrong, it did so because it was the right way to do things. Windows was making 'convenience' features for the lowest level of users while not even considering security or safety while Linux was following the Unix lead with a proven track record (with a small number of exceptions).
There are many more examples of poor design and/or implementation in Windows: eg on booting, the network started before the firewall was activated giving a (small) window where it was vulnerable. That was because the firewall was an afterthought and was later patched onto the system instead of being designed in.
* There was a plus pack that catered for this. OEMs often added 3rd party software that would connect.
"When the initial retail Windows 95 came out it did not connect to the internet* but instead only connected to the original MSN, a private network for Win95 only."
not entirely true. The 'plus pack' had Intarweb Exploiter in it, and I think it was a free download if you subscribed to MSN at that time, which ALSO installed a *real* WINSOCK connection to the intarwebs. I forget the details since I beta tested MSN before '95 was released, as well as '95 itself [and the plus pack - Hover was a pretty cool game] so I snarfed up a really cool MSN login/e-mail name with no suffix numbers [the only reason I keep sending them $4.95 per month, to keep it; that, and the 'emergency' dial-in access for those times that I've needed it].
Ah yes, the days when the number of search engines were few, and many of them were manually edited for appropriate links and content, and Mirsky's "Worst of the Web". And no F'ing JAVASCRIPT.
But seriously, '95 came WITH dial-up internet access if you subscribed to MSN. Out of the box. CompuServe didn't have that for another year or so.
"Unix which was created before WIndows, strongly formed the basis for the design of LInux."
So what? The Unix of the day was decidedly unready for the WWW prime-time it was about to be introduced to. I know this because I was there.
And many upon many of the issues we face in the WWW reality of today are facts of life because of naive design decisions made in those heady Unix-only days of ARPANET, when "Bad Guys" weren't really bad, just mischievous pranksters.
> So what? The Unix of the day was decidedly unready for the WWW prime-time it was about to be introduced to.
And I suppose you think that MS-DOS and Windows 3.1 was ready ?
Unix _was_ the prime-time of the WWW (along with NeXT and DEC). Windows was nowhere.
Er, No, Shellshock WAS a bug, in a very DUMB feature. It inherited function definitions via environment variables (because that's cooler than reading a file), and executed the string it found to passively instantiate the function.
But it didn't check where the function definition ended, and careened off the end, actively executing everything afterwards, e.g. ":(){:|:};:&reboot".
Traditionally, if an env var isn't explicitely referred to, no matter its name, it has no power. Bash made it so that variables of indeterminate name now insert code into its mind. That's still a bug in my book, even without Shellshock misparsing.
ONLY bash needs CGI variable name sanity checking - all the other competing shells do not as HTTP_* has no power over them.
Snaps include their own dependencies, a bit like a statically compiled binary.
To push them as a solution for software vulnerabilities is perverse. If a hole is found in an old-style unix library, it alone can be patched and all its traditional, dynamically-linked, dependencies are automatically protected (you may need a reboot). With snaps, you need every single snap that uses it to be updated.
While I agree in principle, it does make some sense for outward facing applications though: You can *immediately* patch a vulnerable app in glorious isolation - without checking, or even thinking about wider system dependencies/stability.
Now, hackers can exploit Dirty COW to launch a DDOS from actual cows.
From TechRepublic: IoT for cows: 4 ways farmers are collecting and analyzing data from cattle
How so, what was snaps called before Ubuntu copied it from Windows?
"Ubuntu Core 16 for IoT .. comes as Linux reels from the unearthing of the latest hidden code bomb to have put users at risk.
Do you mean all those cheap webcams out there with default passwords that were used in a DDOS attack?
Snaps is basically the same as static linking or Windows manifest. You have lots of copies of the same code floating about. If a lib in that soup has a vulnerability, you must fix all the snaps/apps. IoT devices just don't have the space for such a wasteful system.
The only true solution is for IoT to have auto discoverable standardized hardware, like PCs do, and to be unlocked so peoples/companies other than the neglectful vendor can update it. Think OpenWRT, but without a different binary release for each supported device. But OpenToaster, OpenWashing, OpenCooker, etc etc, with different projects, and even closed IoT OSs people can have if they want.
These things are general purpose computers on the internet and as such they must be properly updated, but they are also small, so how they are updated can't be wasteful. Plus snaps wouldn't solve the kernel/platform/BSP problem.
As a rule, hardware vendors are crap at software. They like to thing their software is cheap differentiation, but in reality no one wants their crap bloatware. What hardware should do is just hardware. They make a hardware to a standard, and then software competes on top of that hardware competition.
At the moment vendors make IoT devices out of a mix or open/close, old/new, then release and forget. Each a unique snowflake no one can update, sometimes including the vendor themselves.
the real solution is a lot more obvious: don't expose them to the public intarwebs without a secure shell of some kind that uses an actual LOGIN...
best way to handle that is an ssh tunnel capability in your firewall. that would mean running sshd on every firewall system out there (quite possibly on a fixed IPv4 address, or an IPv6 address), with PROPER security even, and allowing ONLY properly credentialed users to secure-tunnel into your network to access the devices (say 'phone application with an assigned ssh cert'). THEN all of the IOT devices won't use UPnP to tunnel past the firewall and listen on the intarwebs, or even use publically viewable IPv6 addresses for the same purpose, but would INSTEAD listen on a private LAN IP [and/or non-public IPv6]. The sshd login would then become the 'single point of failure' so the firewall makers would have to goad people into setting it up PROPERLY, then SHUT! OFF! THAT! HIDEOUS! SECURITY! CRATER! known as 'UPnP support on the router'.
/me notes my FreeBSD computer serves as firewall, router, IPv6 tunnel, web server, and sshd for remote access, on a fixed IP, with a 'godaddy registered' name server running, and a few other things. Ok most people don't want this, but if EVERYBODY HAD TO DO THIS to get IoT to work right, it would be a HELL of a lot more secure!
the alternative would be a cloud-based "solution" involving a) a 3rd party sshd-based cloudy server, b) connect to it from your network directly using a daemon/service/whatever to connect your LAN to the service, and c) tunnel through that connection from the 3rd party sshd, through that daemon/service/whatever [which could JUST be ssh invoked with the proper parameters], so that the connection works on both ends.
Anyway, IoT devices using such a service would be as secure as the ssh config. But at least it would become a stumbling block to scanning the ENTIRE address space looking for poorly configured TELNET on IoT devices...
Sure, you can push security updates out for a while... but eventually, someone will break the signing key. Then your IoT device, many of which have short lifespans but all too many remain in use for decades (like, say, your car festooned with IoT? your security camera which works good enough?), will suddenly get APT invites to the land of botnets and accept them.
It is an improvement over the current braindead implementations out there now though.
The only real solution is, well, planned obsolescence. The device stops working when the key set is projected to be "too weak to resist attack". Manufacturers will love it! A selling opportunity based on security! Sadly, it might be appropriate.
"The only real solution is, well, planned obsolescence."
yeah we'll have your web-capable self-driving car just STOP WORKING one day. Fun.
Seriously, though, I proposed 2 possible solutions that would actually WORK, both of them involving ssh. Phone applications would be forced to tunnel into your private address space to access IoT devices. Anything with a publically-facing IP could (in theory) ssh tunnel into a 3rd party "connection" service for similar tunneling capability, in case it has a dynamically assigned IP.
maybe I could experiment with this. I got a couple of arduinos, some sensors, and a couple of WiFly shields banging around... set up a very private LAN for those things, etc.. Write a 'droid application to tunnel through and use TCP/IP through the tunnel to access the devices, for proof of concept. Yeah, might work!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
