Making sure software stays insecure [pdf] | Hacker News Reader

Making sure software stays insecure [pdf]

cr.yp.to

94 pointsthristian39 comments

FYI, for Internet-sourced files, both Windows and Mac (though I've only firsthand knowledge of Mac via mdfind/spotlight) actually do keep track of the source of files. Hence the extra message you get of: you downloaded this program from X on Date; are you sure you want to run it?

Of course, like antivirus, this is only as useful as the security-mindedness of your users. The most secure approaches that I'm aware of involve both locking down the systems to prevent unauthorized OS modifications (e.g. Chromebook, iOS, etc.), combined with a whitelisting of all applications or activities allowed on the system, and tracking of extensive audit logs on Windows to a remote server such that abnormal behavior can be detected quickly. Automatic updates are a must, though I'd rather certificate pinning were used given governments level exploits of Microsoft's certificate (since revoked) to install spyware via Windows Update. Ultimately... How can you be so right to say 2014.07 is still insecure but then not acknowledge that security is system-specific? My definition of insecure activity may differ on a case by case basis, because security, ultimately, is made up of tradeoffs, restrictions and oversight. And it's not just software, as humans indeed can be the weak link, but ideally most secure systems create environments to prevent or monitor this.

His ideas about subverting the security community are interesting.

But I think his emphasis on knowing the source of everything is weird. In my opinion the main security responsibility of the kernel is to not let users escalate, preventing users from writing and modifying where they shouldn't, and reading what they shouldn't. Followed by preventing denial of service by enforcing quotas.

His idea about tagging source for processes based on what files they read, and then tagging written files with those sources sounds like a bad one. I think many processes would read files from a lot of unrelated users, which would lead to noise. Tags seem to pile up, as there is no principle for how to remove tags. Tags are contagious, for when a commonly opened file (say a conf file) is written by an editor, it acquires tags of all files opened by the editor. When the editor creates an output file, all the conf-file tags are transferred over.

When everything has source *, people would just stop caring.

So long as what tagged it is in there too, there should be enough power to make useful decisions easily.

He probably assumes that processes are usually short-lived or limited in their scope (that's the design principles he used in his software, anyway). That way "source creep" doesn't happen so quickly.

It reminds me of the taint principle (-T) as provided by Perl 5. The differences are that there the set of sources consists just of "secure" and "insecure", and processes themselves are not tainted. In a world of C programs, tainting processes themselves (as they become in contact with a potential "contagion") may actually make sense.

Reminds me of a similar talk Poul-Henning Kamp gave where he presents a thought experiment on how it would be possible to subvert open source projects to ensure the priority is insecurity http://youtu.be/fwcl17Q0bpk

The ideas presented here are somewhat similar to IX[1], a security-oriented operating system implemented by Doug McIlroy (inventor of Unix pipes) starting from Tenth Edition Research Unix.

[1] http://www.cs.dartmouth.edu/~doug/IX/

The slides repeat themselves, and have a line length of ~5 words, so I made a reformated version

http://pastebin.com/UW2hc2vZ

I didn't find this very readable, so I've added formatting.

https://github.com/pflanze/slides-djb-20140710/blob/master/s...

I like how this thought experiment leads to questioning the current security orthodoxy. The "security community" is made to serve at least two masters: If security works, forensics can't work. If forensics works well enough to have standard tools, that implies longstanding unresolved security problems. Yet many security consultants work both sides of the fence.

I don't really understand what's the point of tracking the sources when copying files? A security policy which restricts my actions over an object I had copied (with permissions to do so) seems a bit strange to me. But the slides don't really explain why this is wrong?

I'm frankly puzzled by this as well.

1. Why is it a mandatory requirement?

2. How can it possibly be uniformly implemented.

E.g.: curl <some source> | perl -e <some filter> > file

How the hell is _any_ OS going to track origin of 'file'?

What _is_ origin of 'file'?

Add an arbitrary number of netcat-over-UDP transfers between start and end of process.

Ownership/origin metadata is impossible to track unless it's overlayed on every single bit of of information transiting every process and every network node.

djb simply does a massive hand-wave over this, as far as I can tell. I respect the man a lot, but this totally loses me.

Listing the most immediate network connection as the source helps reduce a lot of questions to "do you trust this url?".

But with a web of trust, you could also identify multiple remote sources as belonging to the same entity.

It seems simple you just give an OS program the URI necessary. The program then performs the download and tags it with the relevant metadata.

The example you give would be a bit more complicated, but you would just rewrite curl to attach metadata to file descriptors. Then the OS can have some restrictions about certain programs reading from file descriptors with metadata it deems untrustworthy.

How is this different than the concept of 'taint' in Perl? Or setting meta data on a file object?

    mdls -name kMDItemWhereFroms slides-djb-20140710-a4.pdf 
    kMDItemWhereFroms = (
        "http://cr.yp.to/talks/2014.07.10/slides-djb-20140710-a4.pdf",
        ""
    )

Set some metadata on process streams. One could write a kernel module to track this flow.

I'd love to set filters on file actions like, "after an image/pdf/etc has been downloaded prevent any program from loading it until it has been scrubbed through a whitelisting format normalizer running in a VM" if problems are found, alert and blacklist source.

Free technical PDFs make a great vehicle into a research org.

Taint isn't telling you who data came from. Only that it was external to the program. That's a much simpler challenge, particularly as it takes place within a single process's context.

This is kind of a core principle of mandatory protection systems (Class B for people familiar with the old orange book).

Without this, it because difficult to ensure security policies are subverted by users. There are also some really powerful security benefits when essentially nothing is anonymous.

it stops at sharing. what he describes works OK on the OS. In fact, mobile OSes start enforcing similar stuff.

RSBAC, SELinux, what not, did this for years. NSA you say? SELinux codebase is ridiculously small. It's the concepts that matter, and you know what? These tools are just patchwork for the current OSes, knowingly so. They're far from the silver bullet.

When you add the web its harder. What if Frank's computer is offline? What if its slow as hell?

=> you get these files from google which you do not known, is an abstract entity, yet you trust.

What if you want to modify the file? => Now you own it. Including the potentially bad parts.

Now, there are quite a few attempts at writing secure software with a much more complete concept, much closer to the silver bullet.

There is NO financial interest in it. No financial interest means we'll get there very slowly. Plan9 died. singularity died.

What's left? Living with a larger risk is whats left. That's why risk analysis is used for security (just as its used elsewhere). NIST's framework isnt actually dumb. Sure, dollars should probably go into secure software - but that doesn't mean that today sysadmins will make stuff more secure by "not watching logs or updating to 2014.07 when 2014.06 has a remote exploit".

All that to say the PDF is interesting due to whom has been writing it but it's confused and he hasn't found the direction he's looking for yet.

For as long as we keep re-inventing the wheel, there will be holes in the spokes. For every company that reinvents a daemon process, there's another set of security holes to be exploited. Its human nature to continually alter working/running systems, throw away code, etc. These are cultural/ethical issues which the security spooks know they can continually exploit, and have done so for centuries.

The problem with security is entirely an ethical one, and not at all technological. No amount of technology can make up for an ethical dilemna. What we have with the NSA/GCHQ/five-eyes is entirely a cultural artifact perpetuated upon us all by those who stand to profit - greatly - from hatred, distrust, enmity among people. The fact is, as long as we continue to support the machinations of the military-industrial complex, and its endless streams of justifications for why it is we need to 'hate those people', we will be subject to their rule.

Shut down the warrior class, and we have a better chance at a secure future.

There are times when the wheel at hand is an ill fit or perhaps there genuinely is a better way to do things Ex: Libressl. And so the wheel needs reinvention.

Reinvention of the wheel, reimplementation of a paradigm or some other repetition in a slightly different or totally different way isn't necessarily a bad thing as long as the underlying concepts are well understood and it is executed with competence. I still believe malicious tampering is unnecessary when carelessness - or tiredness - on the part of the developer will do just as well.

I'm not sure that you can use LibreSSL as an example of something that is a "genuinely better way to do things", given that it's an essentially brand new project. There are reasons to believe it's a better way to do things, but we won't know how well it performs until there's time for people to start trying to exploit it.

Is there a video of this talk? It's kind of annoying to read the same thing over and over again because the slides repeat themselves.

Use the presentation mode of a proper PDF reader to go through the slides.

So an OS kernel constitutes a reasonably sized TCB, but a browser is "massive" and "very expensive" to check? Should I look for that on #StuffHNSays, or is there one just for DJB?

The bulk of the code in a kernel is device drivers for hardware you don't have. The software attack surface is reasonably small and well defined in most cases. As opposed to a browser, where close to 100% of the code is exposed to hostile network traffic.

I don't believe the kernel attack surface is as small as you seem to think, nor is the browser attack surface as large.

Let's look at the kernel first. Yes, the LOC numbers are bloated by bazillions of drivers, but even the core components that most people use are pretty large. I just counted on Linux 3.16 and there are 1.2M lines in components I definitely use on one machine. That's excluding anything in drivers/; include what I use from there and we're probably over 2M. I don't think any reasonable person can claim that 2M lines is a small attack surface, so DJB is already wrong.

Now let's look at Firefox. Downloading 30.0 I see ~13M lines of C, C++ and JS. Subtract at least 2M for the build system itself, build-time-selectable components, dev tools, and NSS which is part of the OS attack surface as well. There are a bunch of other components that I'm sure most people never use, or even have explicitly disabled/blocked, but let's leave them in so we have 11M. Hey, 11M is still larger than 2M, so you and DJB must be right. Not so fast. Attack surface is not just about LOC, and certainly not single-component LOC. Let's look at some other confounding factors.

* The exact same algorithm, with the exact same attack surface, can be expressed in more or less verbose form. The Mozilla code is written in a more verbose style, but shouldn't necessarily get credit for that. In many ways, that's likely to make auditing harder.

* The kernel code is harder to audit. There are fewer people even remotely able to do it, it contains more low-level trickery requiring expertise in a particular platform to analyze, it has more asynchronous/reentrant/etc. control flows that defeat static analysis, etc. Line for line, analyzing kernel code is many times harder than analyzing Mozilla code.

* Across an entire enterprise, the number of platforms and drivers that need to be considered for the kernel - from phones and embedded devices to servers and desktops - increases significantly. So does the attack surface, and real security isn't about single machines in isolation. The corresponding increase for Firefox is very small.

* An operating system is more than a kernel. Even if we only include the utilities that are essential to boot a system and do minimal work on it, we might blow right through that 11M mark.

So yes, if you pick silly definitions and squint hard enough, DJB's statements about the two attack surfaces might be pedantically correct. They're still not practically correct. He frames it as "easy" vs. "hard" - a qualitative policy-driving distinction - and that's misleading at best. Even if you can't accept that he got the relative difficulty exactly wrong, it's clear they are well within the same ballpark. The supposed continental divide that DJB uses to justify the rest of his argument is in fact vapor-thin, and deserves derision.

As someone who does this work for a living, none of the factors that you employ to bridge the gap from 2MM to 11MM seem valid:

* Mozilla's code isn't larger because it's "more verbose"; in fact, kernel constraints often make kernel code more verbose --- for instance, the lack of a full-featured standard library for the kernel mean basic algorithms are often repeated, and everything is done up in fiddly structures to try to minimize memory footprint and maximize locality.

* The kernel code is not harder to audit. Kernel concepts can be harder to work with; there aren't that many developer/auditors that understand the implications of inconsistent TLBs, or for that matter what a TLB is. But that describes a small fraction of the kernel code overall. The code itself is straightforward.

* I don't even know what your third point means.

* An operating system is more than a kernel, but the TCB of an operating system is the kernel, and that's what we're discussing.

But despite the yawning gap between the (huge) size of Firefox and the (relatively small) size of the Linux kernel, the difficulty in securing a browser isn't about code size. It's reducible to just a few issues:

* A collection of rich content languages (particularly HTML, CSS, fonts)

* A content-controlled programming language

* The programming language runtime has object lifecycles constrained to individual pages

* The browser has an event system with state shared by every page

* The language has hooks into every feature supported by the browser

Anyone who has ever built a large-scale distributed system with, for instance, timers knows what a nightmare they are to debug. Object created, object manipulated, timer set on object, object destroyed, timer fired, segfault. Take the cross product of that bug with 150 different features. That's a small part of what browser security people have to deal with.

(almost all of the TCB of an OS is the kernel, is what I should have said)

I do this work for a living too, Tom. In fact I've been working on distributed systems longer than you. I was writing about the dangers of relying on timeouts in distributed systems a decade ago. Your appeal to authority will get you nowhere.

The problems you describe in your last paragraph aren't browser problems. They're distributed-system problems - synchronization, coordination, cache consistency. They're problems in systems that just happen to include a browser as a component, and they also happen in systems that just happen to include a kernel as a component. You don't get to count those problems as part of the browser domain and exclude them from the kernel domain. That's totally disingenuous. As a distributed file system developer I deal with exactly these kinds of problems every day, in a context where browsers are irrelevant.

The fact remains that validating either a browser or a kernel as a TCB is extremely hard. It's not one easy and one hard, so we must choose the easy one. Sure, people who know nothing about the constraints that guide kernel programming might dismiss "fiddly bits" that they don't understand as needless complexity, or turn away from them entirely to comment on the remaining "straightforward" bits as though they were the whole. Sophists might use "I don't even know" as an excuse to dismiss a relevant point instead of engaging on it. Every developer likes to think that their own domain is the most challenging and important one ever, so they can feel all elite. So be it. Still, none of that changes the fact that DJB's argument was ridiculous. The reason we can't trust the browser as a TCB is because they were designed to requirements that are antithetical to that purpose, not because they're actually or inherently too complex.

I do get to exclude them from the kernel domain, because the kernel doesn't export a programming language that interfaces with the scheduler and with the various object lifecycles in the kernel (not to mention the programming language's own object lifecycles) --- and there are more different kinds of objects in the browser than in the kernel.

I'm a kernel person, not a browser person. I am not good enough at software security to be a good browser security person. It's not a coincidence that the best researchers in the industry spend much of their time discovering and weaponizing browser vulnerabilities.

Bernstein's argument is, predictably, not ridiculous.

I do not see daylight between your explanation of why browsers are insecure and Bernstein's. You say browsers are insecure because they're required to be complex. Bernstein says browsers insecure because their complexity makes it hard to isolate a TCB. Those are the same arguments, in different terms.

(My resume is pretty easy to track down if you want to see what I was up to a decade ago. When I said "do this for a living", I meant "software security research", which is my full-time job and has been for ~10 years, not systems development, my former job. Also, FWIW: prefer Thomas.)

>It's not a coincidence that the best researchers in the >industry spend much of their time discovering and weaponizing >browser vulnerabilities

It's not a coincidence, but complexity isn't the only possible explanation. Attackers like to go after easy targets, and nobody's saying that browsers aren't easy targets. I'd say it's because browsers are built around a fundamentally flawed security model that provides inadequate isolation between various users, resources, and activities. That could be true even if browsers were ten times simpler. Others might point to prioritizing other goals (e.g. rendering performance) over security, or even say that browser implementers are just less skilled than kernel implementers.

> You say browsers are insecure because they're required to be complex.

No. I said they had conflicting requirements, but I wasn't talking about complexity. I was talking about things like plugin extensibility and interoperability with protocols and formats that are themselves insecure. Those requirements don't have to drive the insane LOC figures for browsers, but it's hard to be secure when you're exchanging bodily fluids with every plugin writer in the world.

Instead of beating this dead horse any more, perhaps the more interesting discussion is whether browsers can be secure. Or is the fundamental concept of a "browser" - a single program to mediate all kinds of protocols, intermingled with presentation and even execution of arbitrary code all in the same address space - just a security anti-pattern at its most basic level? If you have a component that tries to pretend it's an OS, but is essentially not capable of being a TCB, maybe it's not the component but the whole architecture that's broken.

You're ignoring all the user space libraries that the browser uses and a kernel does not. Heck, glibc alone is over 2 million lines of code.

To most programmers, libc is indistinguishable from the kernel. Do you actively distinguish between sections 2 and 3 of the manual, or know which calls in section 2 are actually just libc wrappers for kernel functions that do something slightly different? Libc would more reasonably be considered part of the OS than part of the browser.

You might consider it part of the OS, but it isn't part of the kernel. For purposes of understanding whether the kernel is "bigger" attack surface than a "browser", you can't ignore the runtime.

Well, then this discussion could have been really short, because of course the browser relies on the kernel so the kernel is part of the browser's attack surface. :rolleyes:

That's quite different. The kernel has security responsibilities that are independent of userspace, and vice-versa. It's not like the browser gets loaded in to kernel space.

Stick a JIT-compiled Javascript engine in the Linux kernel, give it bindings to everything from the tty drivers to the scheduler, and add an "eval" system call, then see if you still think an OS is harder to secure than a browser.

Comparatively speaking, the functions of an OS kernel are fairly small and contained. Sure, you can find bloated kernels out there and small secure browsers, but I can read the kernel portion of the POSIX specs without crying. I can't say the same for all the browser specifications out there.

> I can read the kernel portion of the POSIX specs without crying.

POSIX is an incredibly poor guide to what a modern OS does. Even in the parts related to storage, they're hopelessly outdated - either forcing onerous compatibility with systems that haven't been sold in twenty years, or completely failing to address issues that have gained in importance over that same time. The network parts are even worse. There isn't even a POSIX spec for virtualization, and internal issues such as NUMA or PCI/USB enumeration were never under their purview to begin with.

If the requirements for a modern kernel were specified to the same degree as those for a modern browser, they'd be much longer. Note that external protocols and formats are not part of the browser's own specification unless you apply the same rule for external protocols and formats used by the kernel - pulling in a ton of stuff from IETF, PCI SIG, IBTA, SATA-IO, ANSI T10, etc. It's only fair, but again you'd end up with something far longer than the browser equivalent.

The responsibilities of an OS kernel are far deeper and broader than almost anyone out in browser-land thinks. I'm quite sure that works the other way too. Just because it's harder to see detail from further away doesn't mean it's not there.

Show me a browser with a proof of correctness? I'll show you a kernel with one: seL4.

An OS kernel (particularly a microkernel) doesn't actually have to do very much, you know.

This is first-principles brainstorming. As I've already seen it, it's rather hard and almost impossible to follow without the talk, however - just the slides really are missing a lot of it. I'm not sure I follow the arguments in this one either; there's just not enough there about them.

Reply on news.ycombinator.com