6 ms·

Making sure software stays insecure [pdf]

94 points by thristian 12y ago

bluetech 12y 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?
- dredmorbius 12y 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 12y 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 12y 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 12y 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.
    - dredmorbius 12y ago
      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.
- cbsmith 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y ago
  Use the presentation mode of a proper PDF reader to go through the slides.
4ad 12y 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/ http://www.cs.dartmouth.edu/~doug/IX/
notacoward 12y 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 12y 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.
  - notacoward 12y 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.
templeos2 12y ago
atheist-nigger
im3w1l 12y ago
The slides repeat themselves, and have a line length of ~5 words, so I made a reformated version http://pastebin.com/UW2hc2vZ http://pastebin.com/UW2hc2vZ
- pflanze 12y ago
  I didn't find this very readable, so I've added formatting. https://github.com/pflanze/slides-djb-20140710/blob/master/slides.md https://github.com/pflanze/slides-djb-20140710/blob/master/s...
im3w1l 12y 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 12y ago
  So long as what tagged it is in there too, there should be enough power to make useful decisions easily.
- pflanze 12y 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 12y 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 12y 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 http://youtu.be/fwcl17Q0bpk
Zigurd 12y 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.

94 points by thristian 12y 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?

dredmorbius 12y 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 12y 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 12y 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 12y 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.
  - dredmorbius 12y ago
    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.
cbsmith 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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 12y ago
Use the presentation mode of a proper PDF reader to go through the slides.

4ad 12y 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/ http://www.cs.dartmouth.edu/~doug/IX/

notacoward 12y 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 12y 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.
- notacoward 12y 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.

templeos2 12y ago

atheist-nigger

im3w1l 12y ago

The slides repeat themselves, and have a line length of ~5 words, so I made a reformated version http://pastebin.com/UW2hc2vZ http://pastebin.com/UW2hc2vZ

pflanze 12y ago
I didn't find this very readable, so I've added formatting. https://github.com/pflanze/slides-djb-20140710/blob/master/slides.md https://github.com/pflanze/slides-djb-20140710/blob/master/s...

im3w1l 12y 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 12y ago
So long as what tagged it is in there too, there should be enough power to make useful decisions easily.
pflanze 12y 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 12y 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 12y 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 http://youtu.be/fwcl17Q0bpk

Zigurd 12y 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.