Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What should every programmer know about security?

stackoverflow.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: What should every programmer know about security?

#41

Post by lobo_tuerto »

tptacek wrote: post #15

I am wary of software security advice that leads with "don't trust user input", or revolves around "validate user input". That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to start by acknowledging that the verb "trust" is situational, and that in some circumstances virtually all user input is "trusted" somehow. You could ph…

"* I have more than once recommended that people who are very very concerned about platform security (ie, about the likelihood that there are memory corruption bugs in their language stack) use JVM languages."

I thought general consensus was to stay away from the JVM if you mind about security. Isn't that the case anymore? or never was?

Re: What should every programmer know about security?

#42

Post by jkn »

peteretep wrote: post #40
jkn wrote: post #37

Earlier quoted context omitted.

True but perl makes it amazingly easy to exploit. Suppose that you know the source contains this line: open(file_handler, "$userinput"); How much work and what assumptions do you need to exploit this? In perl it's that easy: $userinput = "cat /etc/passwd |zenity --text-info |"; open(file_handler, "$userinput");

> Suppose that you know the source contains this line Then you have a massive damn problem, and you could set up the same strawman about almost any language - if you're starting from the premise that you are piping arbitrary user input to a system call unimpeded, all bets are off. Shall we try some other examples? Let's say you accept input from a user, and dump it unchecked in to output shown to the user via Ruby. O…

I'm in no secret quest to stain Perl's reputation you know... Just illustrating how easy it is to exploit unchecked user input in the open() function. It just happens that this particular exploit is way easier in Perl than any other language I know.

Of course we should not extrapolate from this to make a judgment on the language. Of course it's nice that security mechanisms are available to alleviate this issue.

Re: What should every programmer know about security?

#43

Post by chromatic »

daeken wrote: post #24
bgilroy26 wrote: post #23

Earlier quoted context omitted.

>People will hate me for saying this... Here comes the first pitchfork-bearer! Are there ready examples of what makes the usage of Perl a security liability? By grouping PHP and Perl together, it seems like the security issue you're highlighting is websites made by inexperienced programmers. Perl is much worse than PHP in this regard owing to the fact that Perl's history of being used by people building their first w…

> Are there ready examples of what makes the usage of Perl a security liability? The `open` function used on untrusted input allows arbitrary code execution (I've gotten privilege execution via setuid perl scripts many times this way, as well as getting a shell on the box via web apps allowing this). While there are many other common things I saw in real world apps, e.g. perl scripts using backticks for command execu…

The `open` function used on untrusted input allows arbitrary code execution...

... only if you use the insecure open form. The secure open form has been available and recommended since the release of Perl 5.6.0 in March 2000--twelve years ago.

People who write insecure code, when the language makes it just as easy to write secure code, are to blame for insecure code.

Re: What should every programmer know about security?

#44

Post by bgilroy26 »

jkn wrote: post #39
bgilroy26 wrote: post #38

Earlier quoted context omitted.

Do you usually try $UserInput $Userinput $userInput $user_input etc. when you do that? It couldn't run your code if it had an uninitialized variable in it, right?

It's vulnerable because the user controls the content of $userinput, the variable name doesn't matter. Real code would look like this: #!/usr/bin/perl print "Enter filename: "; $filename = ; open(file_handler, "$filename"); If you see this code, you know that you can execute any command by giving it at the filename prompt and appending a '|' character. For example giving cat /etc/passwd |zenity --text-info | will pop…

Oh I see, I thought you were talking about something that would be caught by the interpreter if you put

    use strict;
and

    use warnings;
in there. Thank you for taking the time to put in an example, I understand you better now.

Re: What should every programmer know about security?

#45

Post by ArbitraryLimits »

chromatic wrote: post #43
daeken wrote: post #24

Earlier quoted context omitted.

> Are there ready examples of what makes the usage of Perl a security liability? The `open` function used on untrusted input allows arbitrary code execution (I've gotten privilege execution via setuid perl scripts many times this way, as well as getting a shell on the box via web apps allowing this). While there are many other common things I saw in real world apps, e.g. perl scripts using backticks for command execu…

The `open` function used on untrusted input allows arbitrary code execution... ... only if you use the insecure open form. The secure open form has been available and recommended since the release of Perl 5.6.0 in March 2000--twelve years ago. People who write insecure code, when the language makes it just as easy to write secure code, are to blame for insecure code.

> People who write insecure code, when the language makes it just as easy to write secure code, are to blame for insecure code

We're not discussing who's to blame, we're discussing whether there's anything to assign blame for.

Re: What should every programmer know about security?

#46

Post by tptacek »

peteretep wrote: post #34
tptacek wrote: post #15

I am wary of software security advice that leads with "don't trust user input", or revolves around "validate user input". That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to start by acknowledging that the verb "trust" is situational, and that in some circumstances virtually all user input is "trusted" somehow. You could ph…

> * People will hate me for saying this but I'm here to offer honest advice: prefer almost any modern language to PHP or Perl. I don't know what to tell you other than that PHP and Perl apps fare worse on security assessments than everything else. If you're talking about copying and pasting formmail.php or .cgi from somewhere on the internet, sure. Beyond that, what exactly is the issue with Perl? Where are the secur…

Look: all things being equal, if

(a) you're just as happy in Python as you are in Perl and

(b) software security is very important to you,

I recommend you select Python. But: lots of people are much happier in Perl and should use Perl. In lots of companies, the best language safety net for security is not a key business asset, and this discussion shouldn't influence them.

I'm not saying that if you use Perl, you're doomed. If your best language is Perl, you're probably better off working in your best language, even where security is concerned.

That's all.

Re: What should every programmer know about security?

#47

Post by chromatic »

ArbitraryLimits wrote: post #45
chromatic wrote: post #43

Earlier quoted context omitted.

The `open` function used on untrusted input allows arbitrary code execution... ... only if you use the insecure open form. The secure open form has been available and recommended since the release of Perl 5.6.0 in March 2000--twelve years ago. People who write insecure code, when the language makes it just as easy to write secure code, are to blame for insecure code.

> People who write insecure code, when the language makes it just as easy to write secure code, are to blame for insecure code We're not discussing who's to blame, we're discussing whether there's anything to assign blame for.

Can you name a practical language in which it's not possible, by default, to perform an unsafe operation with untrusted user input?

I can easily use Haskell's type system to disallow the use of UnsafeUserInput in my database abstraction layer, but that requires me to use my types pervasively and correctly.

Re: What should every programmer know about security?

#48

Post by tptacek »

lobo_tuerto wrote: post #41
tptacek wrote: post #15

I am wary of software security advice that leads with "don't trust user input", or revolves around "validate user input". That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to start by acknowledging that the verb "trust" is situational, and that in some circumstances virtually all user input is "trusted" somehow. You could ph…

"* I have more than once recommended that people who are very very concerned about platform security (ie, about the likelihood that there are memory corruption bugs in their language stack) use JVM languages." I thought general consensus was to stay away from the JVM if you mind about security. Isn't that the case anymore? or never was?

There's a general consensus to avoid clientside Java.

Re: What should every programmer know about security?

#49

Post by peteretep »

tptacek wrote: post #46
peteretep wrote: post #34

Earlier quoted context omitted.

> * People will hate me for saying this but I'm here to offer honest advice: prefer almost any modern language to PHP or Perl. I don't know what to tell you other than that PHP and Perl apps fare worse on security assessments than everything else. If you're talking about copying and pasting formmail.php or .cgi from somewhere on the internet, sure. Beyond that, what exactly is the issue with Perl? Where are the secur…

Look: all things being equal, if (a) you're just as happy in Python as you are in Perl and (b) software security is very important to you, I recommend you select Python. But: lots of people are much happier in Perl and should use Perl. In lots of companies, the best language safety net for security is not a key business asset, and this discussion shouldn't influence them. I'm not saying that if you use Perl, you're d…

But you haven't said /why/, or given any examples, other than "Look! Perl! Security!", where other posters on this exact thread have shown a trend for Perl to have security holes fixed first.

If it's a hunch, or a gut feeling, or a prejudice, just say so. Otherwise, add content.

Re: What should every programmer know about security?

#50

Post by tptacek »

peteretep wrote: post #49
tptacek wrote: post #46

Earlier quoted context omitted.

Look: all things being equal, if (a) you're just as happy in Python as you are in Perl and (b) software security is very important to you, I recommend you select Python. But: lots of people are much happier in Perl and should use Perl. In lots of companies, the best language safety net for security is not a key business asset, and this discussion shouldn't influence them. I'm not saying that if you use Perl, you're d…

But you haven't said /why/, or given any examples, other than "Look! Perl! Security!", where other posters on this exact thread have shown a trend for Perl to have security holes fixed first. If it's a hunch, or a gut feeling, or a prejudice, just say so. Otherwise, add content.

Not interested in adding more content about Perl to my original comment, sorry.
Post reply on HN