Comments on: The Sad State of Computer Security http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/ Academic ramblings about software security. Thu, 02 Feb 2012 14:37:29 +0000 hourly 1 http://wordpress.com/ By: Matthieu http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-279 Mon, 23 Nov 2009 09:19:12 +0000 http://indefinitestudies.org/?p=395#comment-279 Dan is right, even if behaviors are not computable in most of programming languages, you can always compute an abstract interpretation. This interpretation does not provide the exact semantics but can help to decide some security policies.
Though, this is a white/black (green, yellow, purple…) list, it is sad, but I don’t see any other way to do it.
I still think that the problem is to design a specification language that would be abstract enough to be understandable and generic enough to cover most of use cases (and criptic enough to kick off ambigious malicious behovior). Dan are you thinking about yet an other thesis chapter? ;-)

]]> By: dan http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-278 Mon, 23 Nov 2009 07:30:09 +0000 http://indefinitestudies.org/?p=395#comment-278 I think that with open binaries, you can statically compute a safe superset of the program’s behaviour. For instance you could say “this program can delete files” (you did not prove that it will, since it depends on lots of undecidable stuff but you proved that it has the potential to do so).

Again, this does not solve the malware problem but at least it would be a step in the right direction. It would be possible to detect “green binaries” for instance, such as programs that only access the display and sound devices. Think Flash or Java applets, but in x86.

]]> By: Knyghte Hande http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-277 Sun, 22 Nov 2009 23:05:41 +0000 http://indefinitestudies.org/?p=395#comment-277 >> So my questions are ‘How to guess program behaviors ?’ and more difficult ‘How to represent a behavior ?’

That’s right, in my humble opinion: behaviour’s not computable, and that’s why we need heuristics so much.

I love this post, by the way.

]]> By: Knyghte Hande http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-276 Sun, 22 Nov 2009 20:39:23 +0000 http://indefinitestudies.org/?p=395#comment-276 >> But I still believe that if you find a way to specify certain classes of vulnerabilities, then you can have tools that decide if your program is correct with regards to the specification or not.

I’d wish there would be a taxonomy for software …

>> An other point is that a world without vulnerabilties would be better but not free of malware.

I subscribe to Matthieu’s thought. It’d be ideal to imprint speed, flexibility and a great cost-saver to threat analysis with an open specification.

But the bad guys can choose not to follow standards (have they even did?) and keep coding on current binaries architectures (PE, ELF). Hey Thomas More, can you help us here? (no offense intended)

I’d suggest “a new, fehacient, stable and trend-contemplative scriptable programming language, amongst other things.

]]> By: dan http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-273 Sun, 22 Nov 2009 00:10:15 +0000 http://indefinitestudies.org/?p=395#comment-273 > I might be naive, but I think security research is on the right path. It just needs another 15 or 20 years to hit the big time.

this is probably true, but right now I’m in a phase where I feel like a newcomer to things that seemed sophisticated, but then you see how stuff works under the hood and then you’re like “dammit, isn’t that supposed to be computer *science* ?”

(I’m talking about the fact that we have nothing that beats developing with empirical methods in antiquated system languages)

]]> By: dan http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-272 Sun, 22 Nov 2009 00:02:34 +0000 http://indefinitestudies.org/?p=395#comment-272 My scenario is more something like this: what if I give you a reasonably dev-friendly language with really nice safety propertie that outperforms everything out there? Ok this is über-optimism but hey… ^^

]]> By: dan http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-270 Sat, 21 Nov 2009 23:33:48 +0000 http://indefinitestudies.org/?p=395#comment-270 > we’ll NEVER create software without flaws of any type

sure, that’s what I meant by “correct” programs. But I still believe that if you find a way to specify certain classes of vulnerabilities, then you can have tools that decide if your program is correct with regards to the specification or not. Of course you still have potential pitfalls (correctness of the model and the specification), but that would be a nice step away from empirical testing.

]]> By: dan http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-268 Sat, 21 Nov 2009 23:02:53 +0000 http://indefinitestudies.org/?p=395#comment-268 > An other point is that a world without vulnerabilties would be better but not free of malware

that’s right. I like the ‘open binaries’ denomination :) And I agree that open binaries don’t solve the malware problem either, but at least we will be able to get out of the current quagmire.

]]> By: Matthieu http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-267 Sat, 21 Nov 2009 14:55:46 +0000 http://indefinitestudies.org/?p=395#comment-267 As you know I agree with you on both points but you miss some details.
As you said the first way to get rid of memory corruption would be to move to a sound tool chain where programs can be proved safe with respect to memory corruption. There are many such frameworks, then why industry is still using poor old compilers. One answer is ‘it would be too expensive’. When MS releases a new MS Office, they re-use most of the old code and just add some new features. Moving office to a sound tool chain would require to review the whole code, and that would be really pain in the …
That is why smart people such as Podelsky try to patch the tool chain. Providing a new components that would prove a C program to be safe and that would point out all ambiguous cases. This is also a good approach that would help reusing the old libraries. To sum up the Idea, I would like to be the one moving the STL from C++ to any other good language, I would prefer a prover to tell me ‘OK just review theese few functions and the library is bug free’.
An other point is that a world without vulnerabilties would be better but not free of malware. Vulnerabilties help on the propagation aspect but malware such as rogue AV don’t need flaw to exist.
That is why we need ‘open binaries’, I mean binaries whose behavior can be soundly guessed. On this aspect, I think there is still much to do. Indeed you can ensure that a program follow some security politics and I hope that Google will enforce Nacl standards in Chrome OS. Nevertheless, it is not sufficient. Enforcing politics don’t tell you what the program really do and since it is impossible to separe good from bad behaviors we are sill stuck with some kind of black listing but at an higher level.
So my questions are ‘How to guess program behaviors ?’ and more difficult ‘How to represent a behavior ?’. Those are old logician problems (Oops I did it again ;-)).

]]> By: Halvar http://indefinitestudies.org/2009/11/20/the-sad-state-of-computer-security/#comment-265 Sat, 21 Nov 2009 10:09:15 +0000 http://indefinitestudies.org/?p=395#comment-265 Hmm… I am not sure whether I am quite so optimistic. I agree that we’ll get the ‘code execution’ problem sorted, but I am not sure whether we’ll get ‘memory corruption’ sorted. For straight ANSI C with limited indirection of control transfer, yes, but I do not see the same advances in static analysis for C++ code…

]]>