12 ms·

Software Security Is a Programming Languages Issue (2018)

116 points by azhenley 7y ago

m463 7y ago
I loved the perl taint mode. In this mode, perl understands what data originates outside the program and puts restrictions on how you use it. Perl also has strict mode, to tighten up your programming. Without it you don't have to declare variables, but on it requires variables to be declared before use. More languages should help programmers like this - sort of a ladder to go beyond just low hanging fruit.
- claytonjy 7y ago
  Python now has MyPy, a static type-checker which can be tuned to be more or less strict. Pretty cool to see what can be bolted on to a dynamic language.
  - hnick 7y ago
    Perl has various levels of bolted-on type-strictness too AFAIK, I don't have much experience with it due to being stuck on an older version professionally. I personally think it's a great idea. Loose types can get a POC or even early production models up and running quickly while you're changing your opinions on the data every hour, then once it grows to a size that's hard to reason about and static analysis can really pay off, start tightening it up.
vemv 7y ago
Agreed that post-hoc security cannot work very well. Hope it becomes more and more obvious industry-wide. One thing I do to practice "continuous security", is to accompany each code review with an additional code review, solely focused on security. Else it's too many balls to juggle when doing a general-purpose code review. Do you know of similar simple yet effective techniques?
bearer_token 7y ago
Security issues, like other emergent system properties, can arise at any layer of the stack. While code level issues should absolutely be a focus in the SDLC, it's common to find security issues crop up from: * Hardware, kernel, OS, package, and library vulnerabilities * Component integration / API contract misunderstandings * Transitive trust between services and third parties * Accumulation of access over time * Demos, hotfixes, and workarounds that are somehow now mission critical
- AmericanChopper 7y ago
  Even poorly designed business rules create huge number of security issues. The whole stack could be perfectly bug-free and you’d still get those.
  - hnick 7y ago
    Credit card numbers as customer identifiers on printed and emailed documents? Seen it.
  - AnimalMuppet 7y ago
    It can get worse. How about deliberately designed features that are security bugs? I'm looking at Microsoft's "sure, we'll execute any email attachment that the user clicks on, because that's more convenient!". Implementation language wasn't going to save you there...
- throwawaybbb 7y ago
  That can be summarized as: unexpected interaction between independently secure parts. Just because you've written secure components in a safe language doesn't mean you don't have security issues when you run them together.
ngneer 7y ago
Security is the study of control. LangSec and PL have their role to play, but, as others have noted, cannot be expected to guarantee security.
- tptacek 7y ago
  This post isn't really about "LangSec", and I'd ask, in the years and years we've had "LangSec", what have its major contributions been? I find it hard to pin down, and not especially instructive, but I'm prepared to be schooled.
  - ngneer 7y ago
    Mainly its contribution has been the linguistic study of bugs, and the recognition of the importance of well defined recognizers as opposed to shotgun parsers. That is the contribution to theory. In practice, people still write shotgun parsers, because the incentives to avoid them are not there. The market does not reward security. Also, if a programmer has an incentive to alloc() for their program to function but no incentive to check that all control paths free only once, you are left with memory bugs. I think that PL can help with that, but LangSec cannot.
    - tptacek 7y ago
      I don't follow. Parsers for what? I'm never clear what they're talking about. Parsers for programming languages? You don't think modern languages are competently parsed? Parsers for file formats?
      - ngneer 7y ago
        Yes, parsers for incoming packets and file formats, for example. If they are poorly written, you end up with Heartbleed, for example. I should maybe add that the LangSec folks try to provide formal footing for what an adversary can achieve with a given set of primitives. They refer to it as programming a weird machine. The reason that is important is that their view is that access to computational capability amounts to privilege. If you have a packet coming in from the untrusted outside, you should not allow it to be parsed by a parser with unbounded computational complexity, rather you should opt for a computationally limited parser.
tptacek 7y ago
Here's the counterargument: Regardless of language, all software has bugs; that's such a banal argument it barely even needs to be made. Offensive software security is the practice of refining and chaining bugs to accomplish attacker goals. You can make it easier or harder to do that, but in the long run, more bugs classes are going to be primitives for attackers than not. Rust is a fine language to teach people. But what Rust accomplishes for security is table stakes. People building software in Java in 2002 had largely the same promises from their language; Rust just makes those promises viable in a larger class of systems applications. But Java programs are riddled with security vulnerabilities, too! So are Golang programs, and, when Rust gets more mainstream, so too will Rust. Aside: I'm really frustrated by the advice to validate all input. That's not useful advice and people should stop teaching it. It begs the question: validate for what? If you know every malicious interaction that can occur, you know where all the bugs are. And you don't know where all the bugs are.
- hnick 7y ago
  I agree with your last point. A lot of programming advice boils down to "do the obvious thing to avoid the obvious issue" and sidesteps the point that it's the "unknown unknowns" that really ruin our day. 'Taint mode' ala Perl[1] turns non-validated input into runtime errors, rather than security bugs. Crashing is nicer than being pwned. "You may not use data derived from outside your program to affect something else outside your program--at least, not by accident." Bugs still exist (as well as bugs in languages themselves), but languages can help mitigate the surface area. [1] - https://perldoc.perl.org/perlsec.html https://perldoc.perl.org/perlsec.html
  - blub 7y ago
    The validation's still done by the programmer. If they fail to validate correctly or the validation requirements had a bug, taint mode does nothing to help.
    - hnick 7y ago
      True, they can do an incorrect validation but at least they can't to forget to validate entirely. That's a positive step.
sinuhe69 7y ago
To me, the headline is misleading. Security is part of the daily programming job, not just of the security specialists. But as a programming language feature, I’m not so sure. Certainly some languages present a large attacking surface than the others (like generic pointers or pointers arithmetics) but in general, security is a product of process, not a feature per se. It’s naive to believe when I program in a certain language, my program will be automatically secure (or at least more secure than programs in other languages).
- andrewflnr 7y ago
  The programming language is part of your process. To put a finer point on it, your type checker is collaborating with you on a process that results in better security than you would have otherwise. The article starts out talking about a programming languages course, then tries to justify including security therein. I think they're really just hammering home the PL-specific case of your point that "security is part of the daily programming job".
- fulafel 7y ago
  The defenders choices are all like this: you can fix some aspects with each, none are sufficient alone. By choosing a non-footgun you eliminate some classes of problems. It's still important to do it.
Ace17 7y ago
> Software Security Is a Programming Languages Issue Then, how could a programming language help me prevent high-level security bugs like Shellshock? Is it even possible/practical?
- fulafel 7y ago
  Shellshock was a bug in the language implementation so this is an interesting question. It'd need some background on how the bug came to be.
zer00eyz 7y ago
Two malicious Python libraries caught stealing SSH and GPG keys: https://news.ycombinator.com/item?id=21701488 https://news.ycombinator.com/item?id=21701488 Raise your hand if you are executing code in your project that was written OUTSIDE your organization, and has never been reviewed by people within your organization. This is the ham sandwich problem. If a stranger walked up to you on the street and handed you a ham sandwich would you eat it? I would venture to guess that most of you would NOT. However many of us are all too happy to grab some random chunk of code off the internet and shove it into production without a second thought. Personal and social information of 1.2B people discovered in data leak https://news.ycombinator.com/item?id=21606415 https://news.ycombinator.com/item?id=21606415 Is this another ham sandwich from a stranger that has been eaten? How often is the "bug" implicit trust and poor design or default behavior? What about Specter? A hardware level exploit was bound to come up again, we have had hardware bugs before (1994 pentium math bug) but exploitable ones are "fairly rare". ------------ The old mantra "security through obscurity" is true, but it has some serious validity issues when there aren't enough eyeballs on the software we are already running, and were generating more at a rate where people can NOT keep up! (This doesn't address the fact that we are now building opaque boxes with ML that NO ONE understands accurately).
- classified 7y ago
  This may be a field where future machine learning algorithms might shine: Code vetting. It would be hard but much more interesting than classifying cat videos. The amount of code involved in software projects will not decrease and if we don't vet it ourselves, we need something that does it for us. Even if we wanted to vet code ourselves, we might stumble over complexity. Will my software fail in interesting ways if I use library module X this way?
- raesene9 7y ago
  My favourite comparison for all the 3rd party library use is, if you walked in to the CEO of your company and said "we want to hire some people with no background checks, no interviews and no idea where they live to write code for our critical line of business application. We're then going to put that code into production without reviewing it, and regularly update it without reviewing the updates. Oh also we won't have any form of enforcable contract as come-back if something goes wrong." You'd, at best, be laughed out of the room. Yet that's exactly what pretty much every company does with 3rd party libs.
cryptica 7y ago
> It turns out the defense against many of these vulnerabilities is the same, at a high level: validate any untrusted input before using it It should be noted that type safety itself does not solve this problem. For external input, you need explicit schema validation or the type needs to be enforced at the protocol level using something like Protocol Buffers with implicit schema validation. I think that security has nothing to do with the programming language and everything to do with the developers who are writing the code.
fmavituna 7y ago
We need to kill the cliche that language/framework doesn't matter but we also need to understand, it still won't solve all problems. I wrote about a similar topic from a web application security point of view: Why Framework Choice Matters in Web Application Security* ( https://www.netsparker.com/blog/web-security/why-framework-choice-matters-in-web-application-security/ https://www.netsparker.com/blog/web-security/why-framework-c... ) Also today there is enough data in the industry to prove this argument beyond any doubt for web applications. * original article is written about 11 years ago or something this is a republished version
gatestone 7y ago
This excellent presentation was referenced: Secure Design: A Better Bug Repellent Christoph Kern, IEEE SecDev '17 https://s3.amazonaws.com/cybersec-prod/secdev/wp-content/uploads/2017/06/25180810/Keynote-Secure-Design-A-Better-Bug-Repellent1.pdf https://s3.amazonaws.com/cybersec-prod/secdev/wp-content/upl...
austincheney 7y ago
> Why teach security in a programming languages course? Doesn’t it belong in, well, a security course? Because most software developers have no idea what security is. By most I mean almost all. This point is easily proven. Ask any software developer what security is and compare their answer against the standard answer. All security courses and certifications I have seen define security in exactly the same way. If people wanted to take security seriously in software they would train their developers on security or require that they be security certified. > I believe that if we are to solve our security problems, then we must build software with security in mind right from the start. Yes, but clearly most organizations don't take security seriously. Instead they bolt it on at the end just enough to appease the corporate attorneys the same way they do for accessibility or any other necessary requirement whose absence results in class action lawsuits.
paulie_a 7y ago
While programming languages could definitely be more secure. Programmers need to put security first. Currently it's like giving a five year old a gun and saying go play
wglb 7y ago
I disagree with the premise that Software Security is a language issue. There are a lot of basics in this post. However, this is really only a small fraction of the issue in application security. Just thinking back to some recent major breaches recently in the headlines, we have * failure to update (Equifax) * unencrypted backup files (Adobe breach of long ago) * A long-ago root-level compromise of 90 servers of a giant bank. * The Target breach: vendor access to network * Numerous breaches related to improper setup of AWS Also, two interesting SSL/TLS vulnerabilities had nothing to do with anything a language design can address. The GOTOFAIL and HeartBleed. In fact, someone illustrated how to make the same error in Rust (and promptly got downvoted). A good view of front-line security problems is addressed in https://www.youtube.com/watch?v=_4vSurKPl6I https://www.youtube.com/watch?v=_4vSurKPl6I (Attack Oriented Defense.) I have audited applications in many languages, from C, Clojure, .NET, Java, Perl, and Ruby. Vulnerabilities found did not relate to langsec at all.
kephasp 7y ago
It's ironic that the post would say security is a PL issue, but not adress capability-safe PLs like E, Pony or Caja…

116 points by azhenley 7y ago

m463 7y ago

I loved the perl taint mode. In this mode, perl understands what data originates outside the program and puts restrictions on how you use it. Perl also has strict mode, to tighten up your programming. Without it you don't have to declare variables, but on it requires variables to be declared before use. More languages should help programmers like this - sort of a ladder to go beyond just low hanging fruit.

claytonjy 7y ago
Python now has MyPy, a static type-checker which can be tuned to be more or less strict. Pretty cool to see what can be bolted on to a dynamic language.
- hnick 7y ago
  Perl has various levels of bolted-on type-strictness too AFAIK, I don't have much experience with it due to being stuck on an older version professionally. I personally think it's a great idea. Loose types can get a POC or even early production models up and running quickly while you're changing your opinions on the data every hour, then once it grows to a size that's hard to reason about and static analysis can really pay off, start tightening it up.

vemv 7y ago

Agreed that post-hoc security cannot work very well. Hope it becomes more and more obvious industry-wide. One thing I do to practice "continuous security", is to accompany each code review with an additional code review, solely focused on security. Else it's too many balls to juggle when doing a general-purpose code review. Do you know of similar simple yet effective techniques?

bearer_token 7y ago

Security issues, like other emergent system properties, can arise at any layer of the stack. While code level issues should absolutely be a focus in the SDLC, it's common to find security issues crop up from: * Hardware, kernel, OS, package, and library vulnerabilities * Component integration / API contract misunderstandings * Transitive trust between services and third parties * Accumulation of access over time * Demos, hotfixes, and workarounds that are somehow now mission critical

AmericanChopper 7y ago
Even poorly designed business rules create huge number of security issues. The whole stack could be perfectly bug-free and you’d still get those.
- hnick 7y ago
  Credit card numbers as customer identifiers on printed and emailed documents? Seen it.
- AnimalMuppet 7y ago
  It can get worse. How about deliberately designed features that are security bugs? I'm looking at Microsoft's "sure, we'll execute any email attachment that the user clicks on, because that's more convenient!". Implementation language wasn't going to save you there...
throwawaybbb 7y ago
That can be summarized as: unexpected interaction between independently secure parts. Just because you've written secure components in a safe language doesn't mean you don't have security issues when you run them together.

ngneer 7y ago

Security is the study of control. LangSec and PL have their role to play, but, as others have noted, cannot be expected to guarantee security.

tptacek 7y ago
This post isn't really about "LangSec", and I'd ask, in the years and years we've had "LangSec", what have its major contributions been? I find it hard to pin down, and not especially instructive, but I'm prepared to be schooled.
- ngneer 7y ago
  Mainly its contribution has been the linguistic study of bugs, and the recognition of the importance of well defined recognizers as opposed to shotgun parsers. That is the contribution to theory. In practice, people still write shotgun parsers, because the incentives to avoid them are not there. The market does not reward security. Also, if a programmer has an incentive to alloc() for their program to function but no incentive to check that all control paths free only once, you are left with memory bugs. I think that PL can help with that, but LangSec cannot.
  - tptacek 7y ago
    I don't follow. Parsers for what? I'm never clear what they're talking about. Parsers for programming languages? You don't think modern languages are competently parsed? Parsers for file formats?
    - ngneer 7y ago
      Yes, parsers for incoming packets and file formats, for example. If they are poorly written, you end up with Heartbleed, for example. I should maybe add that the LangSec folks try to provide formal footing for what an adversary can achieve with a given set of primitives. They refer to it as programming a weird machine. The reason that is important is that their view is that access to computational capability amounts to privilege. If you have a packet coming in from the untrusted outside, you should not allow it to be parsed by a parser with unbounded computational complexity, rather you should opt for a computationally limited parser.

tptacek 7y ago

Here's the counterargument: Regardless of language, all software has bugs; that's such a banal argument it barely even needs to be made. Offensive software security is the practice of refining and chaining bugs to accomplish attacker goals. You can make it easier or harder to do that, but in the long run, more bugs classes are going to be primitives for attackers than not. Rust is a fine language to teach people. But what Rust accomplishes for security is table stakes. People building software in Java in 2002 had largely the same promises from their language; Rust just makes those promises viable in a larger class of systems applications. But Java programs are riddled with security vulnerabilities, too! So are Golang programs, and, when Rust gets more mainstream, so too will Rust. Aside: I'm really frustrated by the advice to validate all input. That's not useful advice and people should stop teaching it. It begs the question: validate for what? If you know every malicious interaction that can occur, you know where all the bugs are. And you don't know where all the bugs are.

hnick 7y ago
I agree with your last point. A lot of programming advice boils down to "do the obvious thing to avoid the obvious issue" and sidesteps the point that it's the "unknown unknowns" that really ruin our day. 'Taint mode' ala Perl[1] turns non-validated input into runtime errors, rather than security bugs. Crashing is nicer than being pwned. "You may not use data derived from outside your program to affect something else outside your program--at least, not by accident." Bugs still exist (as well as bugs in languages themselves), but languages can help mitigate the surface area. [1] - https://perldoc.perl.org/perlsec.html https://perldoc.perl.org/perlsec.html
- blub 7y ago
  The validation's still done by the programmer. If they fail to validate correctly or the validation requirements had a bug, taint mode does nothing to help.
  - hnick 7y ago
    True, they can do an incorrect validation but at least they can't to forget to validate entirely. That's a positive step.

sinuhe69 7y ago

To me, the headline is misleading. Security is part of the daily programming job, not just of the security specialists. But as a programming language feature, I’m not so sure. Certainly some languages present a large attacking surface than the others (like generic pointers or pointers arithmetics) but in general, security is a product of process, not a feature per se. It’s naive to believe when I program in a certain language, my program will be automatically secure (or at least more secure than programs in other languages).

andrewflnr 7y ago
The programming language is part of your process. To put a finer point on it, your type checker is collaborating with you on a process that results in better security than you would have otherwise. The article starts out talking about a programming languages course, then tries to justify including security therein. I think they're really just hammering home the PL-specific case of your point that "security is part of the daily programming job".
fulafel 7y ago
The defenders choices are all like this: you can fix some aspects with each, none are sufficient alone. By choosing a non-footgun you eliminate some classes of problems. It's still important to do it.

Ace17 7y ago

> Software Security Is a Programming Languages Issue Then, how could a programming language help me prevent high-level security bugs like Shellshock? Is it even possible/practical?

fulafel 7y ago
Shellshock was a bug in the language implementation so this is an interesting question. It'd need some background on how the bug came to be.

zer00eyz 7y ago

Two malicious Python libraries caught stealing SSH and GPG keys: https://news.ycombinator.com/item?id=21701488 https://news.ycombinator.com/item?id=21701488 Raise your hand if you are executing code in your project that was written OUTSIDE your organization, and has never been reviewed by people within your organization. This is the ham sandwich problem. If a stranger walked up to you on the street and handed you a ham sandwich would you eat it? I would venture to guess that most of you would NOT. However many of us are all too happy to grab some random chunk of code off the internet and shove it into production without a second thought. Personal and social information of 1.2B people discovered in data leak https://news.ycombinator.com/item?id=21606415 https://news.ycombinator.com/item?id=21606415 Is this another ham sandwich from a stranger that has been eaten? How often is the "bug" implicit trust and poor design or default behavior? What about Specter? A hardware level exploit was bound to come up again, we have had hardware bugs before (1994 pentium math bug) but exploitable ones are "fairly rare". ------------ The old mantra "security through obscurity" is true, but it has some serious validity issues when there aren't enough eyeballs on the software we are already running, and were generating more at a rate where people can NOT keep up! (This doesn't address the fact that we are now building opaque boxes with ML that NO ONE understands accurately).

classified 7y ago
This may be a field where future machine learning algorithms might shine: Code vetting. It would be hard but much more interesting than classifying cat videos. The amount of code involved in software projects will not decrease and if we don't vet it ourselves, we need something that does it for us. Even if we wanted to vet code ourselves, we might stumble over complexity. Will my software fail in interesting ways if I use library module X this way?
raesene9 7y ago
My favourite comparison for all the 3rd party library use is, if you walked in to the CEO of your company and said "we want to hire some people with no background checks, no interviews and no idea where they live to write code for our critical line of business application. We're then going to put that code into production without reviewing it, and regularly update it without reviewing the updates. Oh also we won't have any form of enforcable contract as come-back if something goes wrong." You'd, at best, be laughed out of the room. Yet that's exactly what pretty much every company does with 3rd party libs.

cryptica 7y ago

> It turns out the defense against many of these vulnerabilities is the same, at a high level: validate any untrusted input before using it It should be noted that type safety itself does not solve this problem. For external input, you need explicit schema validation or the type needs to be enforced at the protocol level using something like Protocol Buffers with implicit schema validation. I think that security has nothing to do with the programming language and everything to do with the developers who are writing the code.

fmavituna 7y ago

We need to kill the cliche that language/framework doesn't matter but we also need to understand, it still won't solve all problems. I wrote about a similar topic from a web application security point of view: Why Framework Choice Matters in Web Application Security* ( https://www.netsparker.com/blog/web-security/why-framework-choice-matters-in-web-application-security/ https://www.netsparker.com/blog/web-security/why-framework-c... ) Also today there is enough data in the industry to prove this argument beyond any doubt for web applications. * original article is written about 11 years ago or something this is a republished version

gatestone 7y ago

This excellent presentation was referenced: Secure Design: A Better Bug Repellent Christoph Kern, IEEE SecDev '17 https://s3.amazonaws.com/cybersec-prod/secdev/wp-content/uploads/2017/06/25180810/Keynote-Secure-Design-A-Better-Bug-Repellent1.pdf https://s3.amazonaws.com/cybersec-prod/secdev/wp-content/upl...

austincheney 7y ago

> Why teach security in a programming languages course? Doesn’t it belong in, well, a security course? Because most software developers have no idea what security is. By most I mean almost all. This point is easily proven. Ask any software developer what security is and compare their answer against the standard answer. All security courses and certifications I have seen define security in exactly the same way. If people wanted to take security seriously in software they would train their developers on security or require that they be security certified. > I believe that if we are to solve our security problems, then we must build software with security in mind right from the start. Yes, but clearly most organizations don't take security seriously. Instead they bolt it on at the end just enough to appease the corporate attorneys the same way they do for accessibility or any other necessary requirement whose absence results in class action lawsuits.

paulie_a 7y ago

While programming languages could definitely be more secure. Programmers need to put security first. Currently it's like giving a five year old a gun and saying go play

wglb 7y ago

I disagree with the premise that Software Security is a language issue. There are a lot of basics in this post. However, this is really only a small fraction of the issue in application security. Just thinking back to some recent major breaches recently in the headlines, we have * failure to update (Equifax) * unencrypted backup files (Adobe breach of long ago) * A long-ago root-level compromise of 90 servers of a giant bank. * The Target breach: vendor access to network * Numerous breaches related to improper setup of AWS Also, two interesting SSL/TLS vulnerabilities had nothing to do with anything a language design can address. The GOTOFAIL and HeartBleed. In fact, someone illustrated how to make the same error in Rust (and promptly got downvoted). A good view of front-line security problems is addressed in https://www.youtube.com/watch?v=_4vSurKPl6I https://www.youtube.com/watch?v=_4vSurKPl6I (Attack Oriented Defense.) I have audited applications in many languages, from C, Clojure, .NET, Java, Perl, and Ruby. Vulnerabilities found did not relate to langsec at all.

kephasp 7y ago

It's ironic that the post would say security is a PL issue, but not adress capability-safe PLs like E, Pony or Caja…