Comments

Chris • December 18, 2012 8:14 AM

Note that it’s not really an exploit in the sense of taking advantage of unintended behavior — having all physical memory be readable and writable by all users is a deliberate design decision that kernel engineers at Samsung made, in order to get their camera working. They had to go far out of their way to make this happen.

derp • December 18, 2012 10:10 AM

I compiled my own kernel with seandroid for an older galaxy phone and stripped out the camera anyways. great success

silverwizard • December 18, 2012 10:32 AM

It seems that is not really an exploit, except maybe a permission issue. The ability to see my memory is important.

It’s a case of you should only install programs you trust, which just makes sense.

Security Engineer • December 18, 2012 11:00 AM

@silverwizard – Users, who can’t tell whether to trust an app or not anyway, are allowed to be lazy. Engineering teams are not!

I’ve been working with engineering teams to implement features securely for a long time. 99% of the time, security and functionality can both be achieved as long as people are willing to work and show a little imaginiation.

Particular Random Guy • December 19, 2012 6:56 AM

What hinders malevolent Apps from (re)enabling the vulnerability just as the protection app does?

openbsd • December 19, 2012 11:59 AM

@bsd: “openbsd devs wont touch rasberry pi due to it being full of broadcomm binary blobs.”

Does the same conclusion also applies to smartphones ?

How about leaving the least possible contact between userland and the necessary binary blobs ?
Is there a particular smartphone which would render that easy ? One close to beagleboard ?

RobertT • December 19, 2012 5:59 PM

who’d thunk-it! memory exploits on smart phones, at least they have kept the exploit data transfer rates by making the memory directly accessible, otherwise the poor hacker would need to construct a side channel comms link to transfer data between the processes. Something like that could be a serious power drain, so good on Sammy for thinking about the battery health and letting the hacker directly access the data they needed.

As they say every cloud has a silver lining.

Clive Robinson • December 20, 2012 3:08 AM

@ Particular Random Guy,

What hinders malevolent Apps from (re)enabling the vulnerability just as the protection app does?

The bug as it currently is allows any process priveledged or not full access to the memoory on this particular uProc chip.

So an unprivileged app can make changes that would in effecct flip the permissssions after which only privileged apps could access the memory in an unrestricted way (including it’s self unless it had upprivileged it’s self first).

This particular attack is so very old (it well predates AT&T’s patent on the ‘sticky bit’ which has long expired) that it’s whiskers are whiter than Dumbldors 😉

bsd • December 20, 2012 12:37 PM

openbsd has arm ports and would prob work with pandaboard tablets. samsung has released propietary binaries for some of their phones on the android site but they don’t allow anybody else to use them for another project like say an openbsd phone.

that doesn’t mean you can’t port it yourself just means they can’t officially do it. the best direction would be to find a taiwanese handset maker on alibaba or something with hardware docs and then port to that device but only if they haven’t filled it with binary blobs.

more and more open hardware and smartphone projects are popping up i bet we see an openbsd phone next yr

Wael • December 20, 2012 12:46 PM

@bsd,

I personally like the bsd derivatives. FreeBSD is what I use for personal work. iPhone (IOS) is based on Dragonfly which is based on FreeBSD, as far as I know. Was looking at PicoBSD a while back, but it is not mature enough. Can you please post some of the links you talked about? Would be interesting to see the security implications of using bsd as opposed to Linux kernel on an Android device.

openbsd • December 21, 2012 3:27 AM

@Wael “Would be interesting to see the security implications of using bsd as opposed to Linux kernel on an Android device.”

The founder of OpenBSD has been crazy on security audits, after[1] having been hacked.
In contrast with OpenBSD[2], the size of the developpment base of Linux and Android has allowed for backdoors[3] (intentionnals ?), which is now a state-funded activity[4]; and code audit works[5] but is not sufficient[6], a small developper base is an advantage for OpenBSD.

But as for OpenBSD on raspberries and other smartphones, there is the problem of closed-spec hardware[7] à la Nvidia.

[1] Quoting http://fr.wikipedia.org/wiki/OpenBSD:
Après la création d’OpenBSD, chaque projet essaya d’attirer à lui des développeurs. Deux camps quasi hermétiques se formèrent rapidement, et plusieurs développeurs de NetBSD suivirent de Raadt. Ce dernier s’aperçut qu’un certain nombre de courriels et de lettres publiées sur son site web personnel avaient disparu. Bien qu’il refusa formellement d’incriminer des membres de l’équipe de NetBSD, Theo de Raadt décida d’examiner la sécurité de NetBSD, qu’il jugea déficiente.

My translation of it (the parts between [] are mine):

After OpenBSD was created [forking NetBSD], each OS [OpenBSD and NetBSD] tried to attract NetBSD developpers. Two communities formed, with negigible contacts between them. Theo de Raadt remarked that letters and e-mails misteriously disappeared from his personnal website [running NetBSD/OpenBSD]. Although he refused harshly to accuse members of the NetBSD community, he decided to audit the security of NetBSD 1.0 [base of the fork], which he assessed as bad.

Feel free to fix my english and post back this translation on http://en.wikipedia.org/wiki/OpenBSD …

[2]http://en.wikipedia.org/wiki/OpenBSD#Alleged_FBI_backdoor_investigated

[3]Linux: http://www.schneier.com/blog/archives/2008/05/random_number_b.html among others
Android: http://www.schneier.com/blog/archives/2012/12/nasty_samsung_p.html among others

[4]http://www.schneier.com/blog/archives/2012/04/buying_exploits.html

[5]http://kerneltrap.org/node/1584

[6]http://en.wikipedia.org/wiki/Underhanded_C_Contest

[7]http://marc.info/?l=openbsd-misc&m=132794042820760&w=2 about openbsd port on raspberry,

Clive Robinson • December 21, 2012 6:56 AM

@ OpenBSD,

… and code audit works but is not sufficient

Code audit usually fails in closed source development.

The reasoon for this is in commercial organisations tthe best programers are usually reserved for adding new features and other similar income related activities. Code audit is usually done not by mainline programers as a primary activity with time alotted in the project, but by team leaders and software testers as at best a secondary activity with usually no time allocated in the project either because it was nnever considered or other primary activities have over run.

I’ve mentioned (moaned 😉 about this in the past and at one organisation I was so fed up about it I very deliberatly slipped a back door into some comms code that used RC4 that actually leaked the key (I did this by freeing a buffer that contained the key and then immediatly mallocing it as a buffer for what appeared to be a random number generator). I waited untill after the code review process was compleated and it was not picked up in any way before pointing it out to the development manager as a fail of the code review/audit process (I should mention I was that fedup with the manager I’d already sorted out my future job security before doing it 😉

That said code audit does tend to work better in some open source environments simply because it tends to be the more experianced eyes looking at the code.

The hard part of putting backdoors in code is not doing it almost invisably but having a valid reason for making modification to the code base in the first place, just in case somebody better than you turns a realy penetrating stare on the code for some reason, or some bored auditor looks through the change logs and then asks why you made the changes….

openbsd • December 21, 2012 4:34 PM

I think it is a pity that openbsd is written in C. This language is a paradise for underhanded backdoors, see my link [6] above.

Does anyone known about a OS coded in another languages ?

Wael • December 21, 2012 4:50 PM

@ openbsd

It’s not the language — it’s the programmer that causes the issues. However, some languages are more dangerous to use because of the amount of freedom and power they give the programer over hardware. When you talk about an “OS”, I am assuming you are referring to the kernel. All kernels I am aware of are written in C or Assembler. I can’t imagine a kernel written in Java or C#, although these may have existed on some smart cards.

openbsd • December 22, 2012 4:55 AM

Wael: “it’s the programmer that causes the issues”

According to my link [4], you can assume the presence of evil programmers among volonteers.

Hence my point [5] shows that C is no more suited for an open-source community-developped OS.

The closest would be the subset of C that comes with the proof that it is correct, here: http://www.schneier.com/blog/archives/2009/10/proving_a_compu.html

It would be better to use for example C++, with the use of pointers limited to one contributor.

openbsd • December 22, 2012 5:47 AM

Oops, typos:

By pointers, I also meant C-style function calls, any public members of class with pointer type, …

By [5] I meant [6].

@Wael: And by “OS”, I meant everything with root-style access on disk, memory or other processes.

Sorry to everyone: this may be a possible double-post, the first post was refused with error “Got an error: Connection error: Can’t connect to MySQL server on ‘db1.XXXXXXX.com’ (113)”; Bruce, write to me at my e-mail adress if you need to know the exact host name.

Nick P • December 22, 2012 12:53 PM

@ OpenBSD

I agree. Many older exemplar OS’s had their kernels or key trusted software written in non-C languages for that reason. MULTICS used PL/0 (or PL/I?), GEMSOS used a subset of Pascal, and Secure Ada Target tried to make an Ada runtime/OS. In my humble opinion, Ada (esp SPARK) is still the best language for writing safe, high performance, maintainable system code. It’s one of the default choices in aerospace for this reason.

https://www.adacore.com/knowledge/technical-papers/safe-secure/

Forget full formal methods like in seL4: they’re too costly and limit you a lot. You want to hit the sweet spot where the tools knockout most easy bugs and many other major ones, but without limiting you too much. Type-safe languages, runtimes, certain functional programming approaches, static verification, and code generators are common ways to do this.

Here’s a few projects for you to check out. Wael might be interested in a few too.

JX Operating System
https://en.wikipedia.org/wiki/JX_operating_system

It’s open source, type safe, has small TCB, employs POLA, and default app language is Java. One of my favorite academic creations in recent times.

SPIN Operating System
http://www-spin.cs.washington.edu/external/overview.html

Probably helped inspire JX. This OS was written in the type safe Modula 3 language (a better C++, imho) and allowed for safe kernel extensions for performance. I’ll add that Modula had a formally verified standard library, too, which might help.

A2 Platform
http://bluebottle.ethz.ch/

This was written in one of the Oberon languages, which are in the Modula family.

Verve Type Safe OS and partially verified stack
http://channel9.msdn.com/Shows/Going+Deep/Verve-A-Type-Safe-Operating-System

Combines microkernel, static analysis, type safe language, and verification technology to prove certain properties down to assembler language level.

Genera LISP Machine
https://en.wikipedia.org/wiki/Genera_operating_system

Let’s not forget one of the original type safe OS’s. The LISP machines were developed to make it easier for AI researchers to develop LISP programs. They used LISP b/c it was (still is) the most flexible language ever developed. One cool thing about many LISP machines was that they had the source of the OS and IDE integrated with the runtime running it. So, if there was a problem, you’d get an exception instead of a crash and you could go right to where the problem was to decide how to handle it.

Other historical notables are…

House – Haskell based OS and/or platform

Flux OSKit – Not necessarily type safe, but it’s a modular OS development kit many typesafe OS’s have targeted too (like MZScheme)

Perlix – It was some people’s project to rewrite most of the user-land UNIX apps/tools in Perl. They succeeded that I recall.

Mirage – Ocaml-based “operating system for constructing secure, high-performance, reliable network applications across a variety of cloud computing and mobile platforms”

StreamOS, TORO Kernel and FP-RTOS were written in Free Pascal.

MaRTE OS is a hard real-time OS for embedded POSIX.13 apps. It’s written in Ada. Apps can be Ada, C or C++ (in development). Already used in a few solutions I think.

Pulse was “an Ada-based distributed operating system” whose kernel was written in C.

Hope readers enjoy looking into these. That C and C++ dominated systems development is an unfortunate turn of history. People who have used other languages know how much better they can be for robust, maintainable software.

Clive Robinson • December 22, 2012 3:28 PM

@ OpenBSD, Nick P,

That C and C++ dominated systems development is an unfortunate turn of history

It might be “unfortunate” history but like all history it is worth considering the causes.

As many people know “C” was called that as it was the successor to “B” which also gave us several other lanquages.

As was noted by one of it’s original designers it was by no means a safe language to use and in fact had the major premise of “the programer knows what they are doing”. However few people ever understood the why of this or the consequences.

The why was that in effect the only other “system languages” around at the time were processor dependant ASM or Microcode. Not at all portable and had many many incompatabilities which time makes us forget untill we bump into them. For instance the support of Octal in C was down to “Data bus width” issues where there were CPU’s with data bus widths of 4,8,12,16,24,30,32 and other bit widths on some systems (I helped design a system with a serial CPU made from ECL with the equivalent of 400bits for reasons I’m not going to go into). Then there were the problems with integers and how the negitive numbers were represented in form (1’s and 2’s comp) and the location and behavior of sign bits (which is why we still have problems with casing up from one int to another).

The problem was that to make C fairly universal the differences in underlying CPU and memory layout had to be taken into account. There were two ways to do this, one was to go vith the CPU’s way the other was to force the CPUs to be consistant. C went for the former other languages went for the latter and got hit by the sometimes masive code and speed overheads. Further the C language it’s self is tiny compared to many other languages, it got around this seeming by the sensible idea of libraries, which had further advantages that gave rise to efficient usage of the then extrodinarly expensive core memory (over 1USD / byte back then say 32USD in todays money) by using efficient linking.

C code when written by a knowledgeable programer could compare very favourably with code written in ASM (ie as little as 1.3times the size) whilst type safe laguages back then could not get in the ball park let alone compete.

I could go on, but suffice it to say most of these reasonss don’t exist any more most of what are considered Personal Computers (PCs/Netbooks/pads/smartphones) CPU’s are one of two types (Intel / ARM). Memory ceased to be an issues some time ago and if it was not for significant App bloat we would not need swap space. We don’t even realy have trouble with floating point numbers due to the IEEE and others.

Do we need C any longer, no LISP and other languages are actually more efficient in terms of programer productivity and keeping bugs low per line of code. And in reality it’s not actually used that much these days C++ in it’s current usage is realy nothing like C and the two are diverging day by day and to be honest the C++ libs have grown to the point where I’m not sure any single person could claim they are both knowledgable and proficient in them all…

openbsd • December 23, 2012 3:22 AM

@Nick P,

Thank you for all the references. Which one is closest to be ported on a current smartphone (multi-core with at least 1GB of RAM) ?

@Nick P and @Clive Robinson:

Now that we have evil volonteers [4], what of the language you listed would have the most efficient procedure of code auditing, in the context of open-source communities ?

Nick P • December 23, 2012 11:08 AM

@ OpenBSD

It’s hard to say. The advantage of those coded in high level languages is that usually only a small portion is low level or platform specific. That’s the part you have to port. You also need a compiler for target architecture, making some obscure languages less applicable.

The first thing I’d suggest you try is improving on an existing porting effort. One I forgot to mention was the Inferno to Android port some Sandia guys did in their spare time.

https://media.defcon.org/dc-20/presentations/Floren/DEFCON-20-Floren-Hellaphone.pdf

They use the Linux layer underneath so they don’t have to write drivers and stuff. This also allows them to update their OS and stack without reflashing. It also reduces the size of the trusted computing base of applications. I’d recommend any porting efforts of yours try something similar, as the Linux part of Android phones is pretty well tested. (You can always remove parts you don’t need, harden it with things like SMACK, etc.)

Another thing you can do with a smart phone that’s lower level is contribute to existing work on microkernels and mobile security. The OCL4 project, Nova microhypervisor, Turaya Security Kernel and OKL4 platform all provide a nice TCB for phones. They follow the model of dividing apps into two types: untrusted, GUI portions running in a paravirtualized OS; critical components running directly on the microkernel. Many demo’s and commercial products already. Look at those and try to contribute to open versions to bring them up to par.

“Now that we have evil volonteers [4], what of the language you listed would have the most efficient procedure of code auditing, in the context of open-source communities ?”

Well, the harsh reality of that is that open source communities tend to work with languages that are popular. They often like C, C++, Java, C#, Python, Perl, etc. These aren’t the best languages for developing safe/secure, high performance systems.

I’d say Ada for smartphones. The language is readable. There’s tutorials online. It’s designed to make it hard to build apps that crash. You can choose how much protection each module gets. Excellent, even GPL, tools from AdaCore for practice. SPARK superset can verify absence of bugs from portions of programs. A commercial release can also use high performance compilers from the likes of Green Hill’s or robust runtimes like Aonix’s.

“Now that we have evil volonteers [4]”

Nah. We just give advice to readers and discuss these things on this forum. I doubt Clive wants to take on an open source project any more than I do right now. I’d rather work on these things with a knowledgeable team in a funded non-profit or sponsored corporate activity. That avoids so many problems.

openbsd • December 23, 2012 11:49 AM

@Nick P: “I doubt Clive wants to take on an open source project”

Sorry, by [4] I did not want to point to Clive, rather to stated-funded piracy schools and state-funded backdoor growing programs.

Thank you Nick P, I will choose one of the projects you just named.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.