Copyright Notice




Unix Review Column 48 (Sep 2003)

[suggested title: ``Computing Securely'']

Security is everybody's business. You may ask yourself, ``Why should I take security seriously? I don't have anything on my system that's worth exploiting.'' Well, that's exactly what the bad guys want you to believe.

Whether you think you have useful data or not, your box provides an identity tied to you, and can be used to mislead the people in pursuit of another exploit, or completely sever the tracks, leaving you holding the bag. And, your machine has resources, like CPU, disk, and network interface, that can be abused by the bad guy to stage larger attacks, like distributed denial-of-service attacks, or monitoring traffic from a new vantage point.

Given that security is everyone's business, let's look at the most common exploits, and what we need to do about them, focusing on the Perl aspects of those points:

Keep your software up-to-date and secure

The latest Perl releases nearly always include bug fixes and code enhancements that improve the security of your system. This was especially true in the great transition from Perl 5.003 to Perl 5.004. If you aren't running at least 5.004, it'd be a very good time to just abandon that old code very soon.

Also note that many of the CPAN libraries get updated frequently, and some of those updates are also security-related. If you aren't using CPAN.pm's r function on a regular basis, you may be leaving yourself vulnerable to the latest attack.

Write code you can understand

If you don't know what your code is doing, how do you know your code isn't doing exploitable or harmful things? There's a lot of noise out there that says ``Perl is unmaintainable'', but I'm going to argue instead that ``too many people write unmaintainable Perl needlessly''. Well-written and documented Perl coded with sound engineering principles is actually quite easy to update and modify.

If you've inherited a codebase that is ugly, please make it a high-priority item to get your boss to let you rewrite your code.

Never trust input data

Exploits generally happen because some part of the data was trusted to be within a certain range or certain shape, and a bad guy did something else instead. Don't trust your input data. Verify that it contains acceptable characters of the right length or right shape. Obviously, Perl's regular expressions help quite a bit here. Also look at things like Email::Valid and Regex::Common in the CPAN to help you with validation.

Additionally, Perl's taint mode can help you track when incoming data has somehow leaked all the way through to some output-affecting operation without being validated. But buggy (or worse, blind) validations can defeat these checks, so don't count on taint checks to do your work for you.

Don't turn data into arbitrary filenames

Another common exploit occurs when input data (either unchecked or improperly checked) is used as part of a filename. When you do something like this, be extra cautious. For example, when you allow an input parameter to select a file within a directory, be sure the input filename doesn't look like ../../../../../etc/passwd.

Keep code and data separate

One security mantra I recite is ``don't let code become data, or data become code''. When your executable code can be accessed like data, the bad guys might be able to determine algorithms or locations of secrets. But worse, if the bad guys can get data they control to become code, you've lost the battle. Be sure you completely separate where your code is located, and where your data is stored. For example, don't put data files in your web's CGI directory: that's just asking for trouble.

Don't let buffers overflow

While Perl has no known buffer-overflow exploits, you might be using Perl to call programs that might have problems. Be careful to limit the size of data you pass to programs when you use system or backticks or qx//.

Beware the NUL byte

Similarly, Perl is fine with a string that contains a NUL ("\0") byte. But many of the system calls and child programs aren't. Again, be very careful that you don't permit such a character to be created (and it's trivial from CGI parameters for example) and then passed on where it'll be misinterpreted.

Don't leave ``debug-mode'' enabled

The famous Robert Morris ``Internet Worm'' exploited a mostly-enabled ``debug'' mode in sendmail to leap from system to system. If you have a debug mode or testing mode, be sure it gets turned off when your system is in production. Don't simply exclaim ``but I might need that if something breaks''. Fine, turn it on when something breaks, but not before.

Don't be too chatty in error messages

Certainly, the user wants to know when something breaks, but usually the user seeing the error message isn't the person who has to fix the code. They don't need to know the precise SQL that triggered the error, or the name of the database being accessed, and so on, because that stuff is all very useful information to a bad guy.

The most frequent violation I see of this principle is when use CGI::Carp qw(fatalsToBrowser) is left enabled on production code. This is wrong, very wrong. The random user at the other end of the HTTP connection needs only to be told that ``something went wrong'' and ``we're looking in to it'', and maybe a unique timestamp so they can report the error. Everything else that would have printed should be captured in an error log somewhere, not sent to the user for exploit.

Watch for timing exploits

Most decent programmers seem to grasp the execution of their program as a single thread. But it takes extra discipline and thinking to understand all the places where a program can break (accidentally and deliberately) when multiple instances of the program are executing.

While this could be an entire article in itself, the two main points here are to generate good temporary filenames (using File::Temp is a good start), and flock your shared data to prevent incompatible simultaneous updates (using the flock function).

Generate cryptographically-strong session IDs

Especially in a web environment, you'll need to have session IDs to track that subsequent page hits are all related. Don't use guessable session IDs, because a bad guy might be able to hijack another user's session if the session ID is guessed, possibly accessing previously entered payment credentials or other secure information. Apache::Session contains an example of a decent session ID generator, but you might also consider Math::TrulyRandom and other similar modules to generate very very hard-to-guess numbers.

Hide your passwords

Don't put your passwords into your scripts! From time to time, someone will ask me, ``hey, can I have the code for that cool thing?'', and without thinking, I'll attach that to my reply mail. Until I made it a habit to put the passwords into a separate file, I revealed my access codes more than once. Putting the passwords into a separate file also permits the file to be lightly encrypted, although anyone with access to both the code and the file can obviously decrypt the data trivially.

Know the protocols

Understand that HTTP basicauth security transmits passwords in the clear. Tools are readily available to sniff the network traffic on a segment and display these passwords. If you care about security, be sure you are using SSL (https:// URLs) for anything that needs to be authenticated securely. Even if you think you're on a secure wire in-house, consider the user at the WiFi access point at the local coffee shop or bookstore, which is trivial to sniff.

HTML attacks

User-uploadable HTML can trigger ``Cross Site Scripting'' attacks, permitting one bad guy to steal the credentials of other innocent victims visiting the same site.

User-uploadable HTML can also execute arbitrary code if the page is server-side-include parsed.

If you have a web application like a message system, chat room, or guestbook, escape the HTML (using HTML::Entities), or control the permitted HTML very carefully (using tools made from HTML::Parser, for example).

Know what you're executing

Have a healthy distrust for scripts from amateur sources. The early web days made heroes out of the early adoptors of Perl, and unfortunately, their legacy is usually a collection of poorly written Perl scripts using old and unaudited techniques. Look at the code, and if you can't understand it, or if you find it looks bad, then don't use it! Ask around if you must.

Avoid the shell

The multi-argument version of system or exec permits a child process to be launched without a shell being involved. This is good because nearly every non-alphanumeric character means something special to most shells, and can trigger command invocations that you didn't intend. For example:

  system "gzip $somefile";

might do a lot more than invoke gzip on a file, if that filename contained backquotes, vertical bars, newlines, semicolons, and so on. So use this instead:

  system "gzip", $somefile;

Now that a shell can't be involved, the invocation is much more secure.

Be careful about your PATH

And just which gzip was being invoked in that last example? Think about your PATH, including where it was set, and how it might change. Watch out in particular for a trailing . (current directory) in your path, or worse, leading <.>!

Be careful about INC and PERL5LIB

The require operator (on which use is built) looks at @INC to determine the list of scanned directories. This list is built-in, but can be affected by arbitrary user code and the setting of environment variables such as PERL5LIB. If a bad guy can control the list, they can replace strict.pm with their own code, and that'd be a bad thing. Don't let that be an exploit!

Use builtins rather than calling a subprocess

Far too often, I've seen a child process used when it wasn't necessary. For example:

  chomp(my $now = `date`);
  system "rm", $somefile;

These are bad from a performance perspective, but also from a security view, as they can both be done ``in house'':

  my $now = localtime;
  unlink $somefile;

thus avoiding an expensive launch of a program. Yes, but which program? The PATH exploit makes these both rather vulnerable to mistakes.

Know the language

You should also continue to master Perl if you want to ensure security. For example, if alarm bells don't immediately go off in your head when you see something like this:

  $input = /(\w+)/;
  my $keyword = $1;

then you need to keep studying. The problem with this code is that when the match fails, $1 is left over from a previous match. This kind of code can be used as a security exploit, if the attacker can access the source code or have an idea that this is happening. It's code that ``looks right'' but definitely isn't.

For further information

I've just barely scratched the surface here. Learning about security is an ongoing process, especially since for every countermeasure, someone is working right now on a new exploit. For Perl security, start with the perlsec manpage included in the standard distribution.

If you've got the inclination, spend at least a month or two reading the BUGTRAQ, CERT, and RISKS mailing lists. If you thought that a virus or two a month was a lot, you might be surprised at the dozens of daily exploits listed on these mailing lists.

And finally, search the web for keywords like ``security FAQ'' and ``CGI security FAQ''. You'll see a lot of common themes in these documents, but I generally find one or two new interesting things every time I look. We can't all be security experts, but we're all responsible for security. Until next time, enjoy!

