Making sure software stays insecure [pdf]

http://cr.yp.to/talks/2014.07.10/slides-djb-20140710-a4.pdf

by thristian • 12 years ago

94 39 12 years ago

cr.yp.to

bluetech• 12 years ago

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?

dredmorbius2• 12 years ago

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.

myhf• 12 years ago

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.

jkolash• 12 years ago

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.

sitkack• 12 years ago

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.

cbsmith5• 12 years ago

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.

zobzu• 12 years ago

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.

fit2rule• 12 years ago

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.

ejr• 12 years ago

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.

x1798DE• 12 years ago

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.

higherpurpose• 12 years ago

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.

nhaehnle• 12 years ago

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

4ad• 12 years ago

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/

notacoward7• 12 years ago

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?

tedunangst• 12 years ago

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.

notacoward7• 12 years ago

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.

tptacek4• 12 years ago

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.

cbsmith5• 12 years ago

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.

notacoward7• 12 years ago

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.

AlyssaRowan• 12 years ago

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.

im3w1l2• 12 years ago

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

http://pastebin.com/UW2hc2vZ

pflanze2• 12 years ago

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

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

im3w1l2• 12 years ago

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.

luke-stanley• 12 years ago

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

pflanze2• 12 years ago

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.

lstamour• 12 years ago

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.

dobbsbob• 12 years ago

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

Zigurd• 12 years ago

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.

Making sure software stays insecure [pdf]

Related Stories