Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Microkernels for browing devices are on their way


  • Please log in to reply
7 replies to this topic

#1 palerider2

palerider2

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 08 March 2017 - 08:27 PM

A recent article on ThreatPost seems to provide unxepected evidence of kernel software being attacked :
I'll just caution that most of the article is about spammers accidently giving away their actions. However, one bit that caught my eye is copied below, from a chat log :
 
"10:57
Sean: [...] then we're stuffing it into the kernel
...
Sean: [...] stuff as much packet data down their throats as possible until they disconnect you "
 
This discusses exploiting a kernel vulnerability, possibly within a comms driver or TCP stack. The objective is to place the attacker's code in the kernel and then execute that code with a high privilege (root essentially). What happens next will vary, depending on the purpose of the attack, but in this case it seem to be about exfiltrating masses of sensitive information from the chosen target.
 
It would be far harder to perform the same task (perhaps even impossible) if the target machine was running a microkernel. A microkernel reduces to a minimum how much code is allowed to execute with high privilege. Whatever code/functions remain in the kernel can then be reviewed much more easily for code correctness. It's a really simple idea - if code is written correctly, it can't be attacked. 
 
If further proof was needed that the traditional (monolithic) kernel of a browsing device was a risk, then consider these facts :
 - in the 2000s, Apple made a huge efforts to create a kernel that was almost as secure as a microkernel. They then deployed it, fairly successfully, in various new products and also in OS X.
- the Qubes project took a different approach by implementing a tiny secure hypervisor and running a distribution of GNU/Linux on top of that
- The Minix 3 project attempted something different again - they wrote an entirely new microkernel, from scratch
 
But, typically, when you write an OS from scratch, you have no drivers. This can sometimes be overcome by creating a layer of software glue that connects certain existing drivers to the brand new kernel (or microkernel). The Minix 3 project did this, giving it access to NetBSD userland and drivers. Those drivers were originally executing in the NetBSD kernel.
 
Within the computing industry, there's clearly a lot of interest in microkernels, and not just for deployment as browsing devices. For example, both KasperskyOS and Redox hope to gain deployment of their new OSes as the hub of ultra-secure network nodes. In this regard they are joined by SourceT. All 3 of those have microkernels. (SourceT is already out there and running on IA-64 architecture. Could be a hint there.)
 
And, returning to browsers, it's my belief that you could still run QNX on a desktop PC, if you were to ask the owners nicely. (Research required here).
 
 
edit: grammar 
==================================================================================================
(Part 2)
Then we had the Aug 2016 announcement from Google, who are building a new minikernel, one which is designed to support both smartphones and desktops. Software engineers, who are known for having prior experience with this technology, are running the project, so success is strongly anticipated. However, it's a minikernel because it hasn't been made as small as possible, this time. The one driver that's being left in the kernel - the graphics driver - will need to be hardened (e.g. be made small and free of vulnerabilities).
 
It's worth noting that whilst almost everyone else is looking at microkernels (of some form, including MS), the Linux project is not. And I also see no current plans for OpenBSD or FreeBSD to investigate new kerneks either. Possibly they pin their hopes  on re-using whatever NetBSD achieves through Minix 3. That would be fairly typical for the various BSDs.
 
Linux can run on top of different types of hypervisor and, in doing so, this gives it a limited amount of protection from its security bugs (which seem to have famously long lives). Qubes is one example of how you can change the architecture of Linux and reduce the risk of privilege escalation. L4Linux would seem to be another solution. However, once the GNU project has released a (much delayed, early-architecture) microkernel of its own, it will be interesting to see the adoption rate of this microkernel (Hurd, as it is fondly known). It ought to be an option in Debian and GuixSD distributions, as a minimum. Present-day attacks on monoliths (such as Linux) will increase which suggests to me that there will be some kind of response from the industry.
 
My suggestion for further contributions to this thread would be as follows :
 - add to the initial list of microkernels
 - document new information for microkernels, as it becomes available
(for example what are the timescales for GuixSD/Hurd and Genode ?)
 - (maybe) discuss other CPUs and any effect that they may have on microkernel design
 - document the acccepted generations of microkernel design ( 1, 2 and 3 ? )
 
There's really only one issue that I would suggest not be discussed here and that's whether the design decisions made during the life of Linux were correct, either at the time, or in hindsight. In 2017, the ability to hack endpoints has reached a level that would not have been predicted, even just a few years ago. Separately, we all know that CPU power has grown massively, so the landscape is different. There are places where you can read about the original arguments over whether Linux should have been a microkernel or not. Interesting history but that's a good place to leave them :-)
 
Genode looks like it has fantastic prospects but I seriously doubt whether I will be able to boot a PC off this OS via a Live CD before 2020. Changes of direction in the RoadMap suggest differing, unresolved opinions within the development group. I know that I would like to use it. Why not give it a marketing boost guys - get lots of people using it ! Genode has the ability to provide a third kernel option for GNU distributions, eventually, perhaps through seL4, the formally verified microkernel.
 
I haven't discussed every microkernel that I'm aware of, so here are brief mentions of a few more: HelenOS, Robigalia, Rux and BlackBerry 10.
 
And since we now have Qubes (for AMD64 anyway), is there a good, fairly technical review of Qubes OS ?
Some project links :
I found this independent review of Qubes to be quite useful and it cites an example platform that you could use :
 
 
edit: grammar and add a few bits

Edited by palerider2, 09 March 2017 - 07:33 PM.


BC AdBot (Login to Remove)

 


#2 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 19 March 2017 - 09:46 PM

Here are some figures which indicate the relative sizes of some of the micokernels mentioned. Members of  Bleeping Computer may be able to provide more accurate figures (in which case, please do so).
 
The figure being quoted each time appears to be 'number of executable lines of code'. I take this to mean the number of machine language instructions in the binary (i.e. post-compilation or post-assembly).
 
uKernel name                           Executable Lines of code
------------------------------------------------------------------------
SourceT                                               <4,000
Minix 3                                                   6,000
L4                                                      <20,000
VxWorks 7                                           20,480
QNX                                                     60,000
 
I wasn't able to find an equivalent size figure for Mach but one source says that it occupies 350KB of memory.
 
I have noted several references which indicate that the Linux kernel core (excluding drivers) has 500,000 executable lines of code.
 
Compared to microkernels, the difference in attack surface of Linux (and others) is an order of magnitude. Increasingly it will be an obvious target for attackers.


#3 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 24 March 2017 - 09:37 PM

Here are some quotes highlighting the point that we run risks by not having microkernels in our browsing devices (and also servers). According to these experts, this is going to be a problem :
 
 
Written on 20th March, 2009, by Joanna Rutkowsa, of Invisible Things Lab :
"The sky has actually fallen many years ago...
Default users with admin privileges,
monolithic kernels everywhere, 
most software unsigned and
downloaded over plaintext HTTP"
 
 
Microkernels prevent escatation of privilege that would otherwise give an attacker access to all of the hardware in the device :
Daniel J Bernstein :
"Happy thought of the day:
An attacker who merely finds a browser bug
can't listen to the microphone 
except when I've told Qubes to enable it."
 
 
Highlighting the purpose of a microkernel, plus what can happen when there isn't one (a nightmarish scenario) and a common method that an attack would use :
Calvin Ratsavong in 2016
"... to protect access to firmware from the communications driver..." 
 
We don't want attackers turning the microphone on to allow our dormant TVs or telephones to become snooping devices. And we certainly don't want anyone messing about with the firmware in those devices - how on earth does the average user recover from that ?
 
More to the point, what if you don't even know that your device has been compromised ? 
(The name 'Invisible Things Lab' is well-chosen.)
 
But is this microkernel problem being overstated ? And is it only a problem for the distant future ? 
 
Definitely not, as my next post will show. Earlier in March (15-17th) there was the CanSecWest security conference...


#4 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 26 March 2017 - 07:43 PM

First, a clarification to the previous post - in the penultimate line I should've written :
"is this missing microkernel problem being overstated ?"
 
Next, one further quote regarding the fact the we generally don't have access to operating systems with microkernels :
 
Security Now podcast #574 discussed some historical issues with the graphics driver that's located within the Windows kernel :
"all the trouble that Microsoft has suffered from the fact that a JPEG can take over Windows ... [It's] just ridiculous.  And if [the driver] were outside of the kernel, [the malware] couldn't do that.  But the actual code that's interpreting the JPEG has root privileges.  It's kernel code.  So [the malware] can do anything it wants to. "
 
And as an update to this: the particular vulnerabilities in the graphics driver quoted above were (of course) fixed, once they became known. However, the graphics driver mentioned is still located in the Windows kernel and other security issues arise with it, periodically, with the same serious consequences. (The driver is sometimes referred to as GDI in some technical notes).
 
 
To the main point ... as if provided on demand, earlier this month, several successful attacks on popular operating system kernels were disclosed at CanSecWest 2017. The data (below) comes from the show notes of Security Now podcast #604 (21st March 2017).
 
Only the briefest of details on each of the exploits is required :
 
1. One team used a Linux kernel 'heap out-of-bounds' vulnerability to attack Ubuntu Desktop
2. Another team attacked MS Edge by exploiting a use-after-free vulnerability in the Windows kernel
3. Team 360 Security attacked MS Windows via an out-of-bounds vulnerability in the Windows kernel
4. A different attack on MS Windows used an integer overflow in the Windows kernel
5. Yet another attack (on Firefox) in Windows used an uninitialised buffer in the Windows kernel
6. there was an exploit using a type confusion bug  in the Windows kernel
7. Edge was attacked again (and also VMware), in part, via a buffer overflow in the Windows kernel
8. Another virtual machine escape (with a $100,000 reward) was based on a use-after-free vulnerability in the Windows kernel
 
I believe it's reasonable to consider that the point about the present-day danger of monolithic kernels is sufficiently well-made.
 
Note also that the Linux kernel is now starting to appear as a target and there's a good reason for this : attackers know that Windows installations (those that are internet-connected) are on the decline. So attackers must move to alternative 'fertile' ground.
 
Just to declare my position: I'm not anti-Windows; I still use Windows every day - it helps me to be productive, but I don't connect my Windows machines to the internet. I also take care what is allowed to run on them as well. The bottom line: I believe that Windows and Linux still have their proper place.
 
To close, a question: can the situation be improved sufficiently for operating systems that have monolithic kernels ? I'm still looking in to that. I already mentioned running OSes under a secure hypervisor (e.g. via Qubes) - the 'guest' OS could be Windows, Linux or something else.
 
 
Edit: typos

Edited by palerider2, 27 March 2017 - 07:01 PM.


#5 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 09 April 2017 - 08:22 PM

About two weeks ago Apple issued release 10.3 of iOS containing (as I understand it) 223 patches. That's quite a lot for Apple, all in one go. If you look in to the details, many of these vulnerabilities were reported to Apple by researchers or by research teams, then patched. I haven't (yet) noticed any vulnerability that was known and used in the wild (i.e. a zero-day exploit). There was also a follow-up update: release 10.3.1, which I won't mention other than to say that both the 10.3 and 10.3.1 updates should be taken over a connection that is absolutely trusted. 10.3.1 fixes a WiFi problem.
 
I mainly wanted to discuss the kernel of several of the Apple products, which is called XNU. The main two points about XNU are that (i) it isn't a micorkernel and (ii) it is large enough to have quite a few vulnerabilities which, if exploited, could result in arbritrary code being executed with the highest privilege. An attacker could wreak a lot of damage on iPhones, iPads, macOS and so on. It has happened in the past. Another trend has been to use known kernel exploits to 'jailbreak' iOS devices. (Not a great idea, incidently).
 
For the recent batch of kernel vulnerabilitieis, this is how the risk is described for each of the exploits: "any application may be able to execute arbitrary code with kernel privileges". Note well: "any application". All 9 exploits are listed below.
 
Here's a summary of just the kernel exploits that are now patched in release 10.3 of iOS. As stated, each one of these was discovered by a researcher or research team. That's good news, as far as it goes. It doesn't follow that none of these exploits was discovered separately by someone else, and not reported. So there may have been attacks. (It does, however, highlight the importance of bug-bounty schemes.)
 
Vulnerability Reported by
1. memory corruption
CVE-2017-2398 Qihoo 360 Vulcan Team
CVE-2017-2401 Qihoo 360 Vulcan Team
2. integer overflow
CVE-2017-2440 anon. researcher
3. race condition
CVE-2017-2456 Google Project Zero
4. use after free
CVE-2017-2472 Google Project Zero
5. memory corruption
CVE-2017-2473 Google Project Zero
6. off-by-one issue
CVE-2017-2474 Google Project Zero
7. race condition
CVE-2017-2478 Google Project Zero
8. buffer overflow
CVE-2017-2482 Google Project Zero
CVE-2017-2483 Google Project Zero
9. memory corruption
CVE-2017-2490 Google Project Zero; UK's National Cyber Security Centre
 
The bottom line is that we have a ready supply of these exploits - the worst kind that exists. We are therefore going to need microkernels in all of our browsing devices. We can't simply go to the current least-attacked platform and say "oh I'll have one of those and I'll be safe".
 
I plan to say a few words about the XNU kernel and its history because it contains elements of Mach, which is the microkernel that was developed at Carnegie Mellon University.
 
I'd be surprised if Apple is not already working on a microkernel, i.e. to replace XNU but, as a company, they're pretty good at keeping their development projects secrets. 
 
In an ideal world, at least some of the present crop of iPhones would be upgradeable to the theorised new kernel.
 
Perhaps some of Google's existing Pixel handsets will be able to run the in-development Fuchsia OS with Magenta microkernel. Don't quote me on that though. I see that Fuchsia now has an icon, which looks a bit like an infinity symbol (it isn't - it's something else). This replaces the fuchsia-coloured square that's been around since announcement. If interested, have a look here :


#6 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 02 May 2017 - 09:25 PM

Apparently Blackberry has just released the
QNX Software Development Platform 7.0
That was towards the end of March.
 
In the first post of this thread (9th March) I wrote : "returning to browsers, it's my belief that you could still run QNX on a desktop PC, if you were to ask the owners nicely. (Research required here)."
 
It appears that this has been proven :-)
 
I refer to this blog, posted on 12th April
 
...and many thanks to Thom on
for bringing this to our various attentions. Thom's article has, incidently, attracted quite a few comments already. (I may return to those because they are potentially highly relevant to this thread )
 
In the wordpress blog, one of the QNX kernel developers, Elad Lahav has shown that the QNX Software Development Platform (SDP) supports porting of posix-compliant packages to the QNX neutrino OS. And he's also gone so far as to create a windowing system. (If I understand correctly, the original windowing system, Photon, is no longer supported.)
 
Further, the present official position is that Blackberry sees no market for QNX on a desktop.
 
However, given the way that internet exploits seem to be veering towards attacking the kernel, I can think of a good couple of ways that a pre-packaged posix-compliant microkernel could be of assistance.
 
In summary, it seems like the option that I thought was there for Neutrino, actually is there. I have a suspicion that we haven't heard the last of this. :-)
 
Mostly: thanks Elad for sparing me the time to research that interesting aspect of QNX.  :thumbup2:
(if you're reading....)
 

edits: Thom's article is here:  https://www.osnews.com/comments/29788
 now try the correct BB code ...

Edited by palerider2, 03 May 2017 - 08:33 PM.


#7 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 10 May 2017 - 11:20 PM

The latest news from Google is that the user interface for the Fuchsia operating system is called Armadillo. Not only that, some early screenshots of it have been made available :
 
(Just to clarify a point about the above URL - Fuchsia is not just intended for smartphones. Desktops are also included in the plan.)
 
With this announcement, it feels a bit like Google are keen to let the world know how it's progressing, which is : quickly. 
 
Similarly with Blackberry and the QNX Neutrino RTOS, the owners appear keen to show that the OS could have a future as the basis of a desktop OS, not just embedded applications. This (below) is where I would expect future links to more news to come from :
 
Got to say that these movements in the industry aren't a surprise - microkernels are now a necessity. (Or, more accurately, secure kernels that are as small as possible are needed. Microkernel being the ideal.)
 
Meanwhile, Minix 3.4 (with microkernel) made another step towards being fully released, so a few words about that... 
 
Release Candidate 6 was pushed out of the door a couple of days ago. Over the last year and a half, one of the developers has been replacing the old, project-generated TCP stack in Minix 3 with lwIP. That's just one of the inclusions in RC6. Find out more and how to download your own microkernel with a NetBSD userland here :
(for the download link, refer to the email in that chain dated 9th May 2017)
 
As far as I know, v3.3.0 of Minix had no capability to use USB ports and I see no report of that having changed. There's a well-developed plan to port Minix to the ARM platform but that's currently awaiting third-party action. Minix can run on either 32-bit or 64-bit Intel architecture but only in 32-bit mode. 1 GB Ram is required. It needs a BIOS boot firmware (UEFI is not supported). It installs from the ISO onto a hard drive. 10 ethernet cards are supported.
 
 
So that's interesting progress on 2 micro/minikernels. And some possible indications of intent from a third - perhaps looking for a partnership. If so, would that be vendor or community ? 


#8 palerider2

palerider2
  • Topic Starter

  • Members
  • 133 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:23 AM

Posted 02 June 2017 - 10:24 PM

Continuing with QNX for a minute, I read that one of the major OS suppliers once made an offer to buy Quantum Software Systems, the original developer of QNX, and this is supposed to have happened before the year 2000. Unfortunately, I can't provide a verifiable source for this statement, so I'll refrain from namin the supplier. Suffice it to say, if that's true and had it gone ahead, I think we'd be in a much more secure situation now regarding internet browsing.
 
The situation with QNX is a rather complex one and further complicated by its widespread use and further potential use in the automotive industry as a reliable OS for autonomous vehicles.
 
Judging by the comments on the wordpress blog and elsewhere, many people found the demonstration of QNX running on a desktop PC quite thought-provoking. I note that the developer seemed to indicate that there was more to come, dependent upon him gaining access to Qt-proficient resources (in the community?)
 
Feels like this is heading somewhere ...
 
 
Every 3 months there is a release of Genode OS Framework and the latest release occurred on 31st May.
 
The release notes are here. There's a lot of detail. 
 
I understand that some people are already compiling and using Genode components for themselves, as indicated by the correspondence in the mailing list :
 
For those who wish to follow this path, the first step seems to be to download the Genode Foundations book, which is linked on the page above (see paragraph 3). 
 
My impression is that the Genode project has produced a limited number of ready-made demonstrators in the past. I noted one, known as Turmvilla. More on that, and on the Genode project direction, to follow ...





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users