Slashdot Mirror
Secure Programmer: Keep an Eye on Inputs
An anonymous reader writes "This article discusses various ways data gets into your program, emphasizing how to deal appropriately with them; you might not even know about them all! It first discusses how to design your program to limit the ways data can get into your program, and how your design influences what is an input. It then discusses various input channels and what to do about them, including environment variables, files, file descriptors, the command line, the graphical user interface (GUI), network data, and miscellaneous inputs."
Doesn't windows throw random crap around?
This unpredictable event seems to screw with programs when the ram is low.
Also, those microsoft security holes we have seen in the past year of 2003 are no confidence to M$ security.
Lastly, Belkin routers are no good for security. AFter all, they hijack your http requests and direct you to somewhere you didnt want to go!
Grump.
Is it true that more people vote for the winner of American Idol, than vote for the president? -Ali G.
The Perl language has built-in "taint-checking" enabled via the -T command line switch which causes Perl to automatically keep track of all information that possibly came from a user input and not allow any of it to do anything harmful (basically end up on a command line or in a file name).
We don't see the world as it is, we see it as we are.
-- Anais Nin
The recommendations on dividing the program into unsecure and secure binaries to handle setuid access in GUI's can very properly be extrapolated to non-graphical programs. This is a very good strategy for allowing relatively wild programs access to important facilities and can involve many types of IPC including memory-mapped files (with proper protection) and sockets. To really secure a client program that needs access to criticals, put it in a chroot jail and have it communicate with an outside process through (e.g.) a socket. Separating programs into safe and unsafe sections and applying different security techinques to each is far more effective, imo, than trying to secure a single, large application. It can also provide many other benefits of encapsulation, etc. The security onus shifts to handling client requests in the secure section which is usually much more easy to do.
Hacking articles at http://www.geocities.com/chroo
"Given that every single way to compromise security involves bad input, it's not surprising that it's in a security magazine."
What about program bugs that are not input related? If a program breaks when an internal timer overflows for example, or accessing a section of memory that has been deallocated. Such bugs can easily cause breaches in security as well as general system failure, all without any human intervention. It reminds me of the black out that Sterling mentions:
http://www.lysator.liu.se/etexts/hacker/crashing.Hacking articles at http://www.geocities.com/chroo
Basic point, I suppose, is that if you insist on using a U*ix-family OS in such an environment then you must ensure that the U*ix environment is clean at the beginning, which may well be more a matter of the procedures and quality control of the platform and the application deployment than of the individual apps.
Oh, and btw, I thought the head of the thread was a kneejerk reaction, but - flamebait? Shame on whoever moderated it that way.
The proliferation of proprietary formats we are seeing that all do basically the same thing, like send sound files over the net, or view video clips, are encouraging mass downloads of programs from third party providers. These programs may well do what they said they would do, but with all this DMCA crap going on, its getting harder and harder to see if they are doing a little extra that wasn't in the bargain, like doing zombie work on the side to assist in little capers the originating author needs to pull off.
What firewall or systems programming can stop a deliberately malicious program installed by an ignorant user? Say the program "demands" access to the internet for "verification/auto-update", then you have to set the firewall to allow this program access to the net. Now what happens? Its like giving car keys to a valet parking agent. You only have to trust he's only going to do what he says he will do. To add insult to injury, consider you generally have signed any recourse you have when you click that "I agree" button that confirms you have read and understood the EULA.
What irritates me so about these "plug-ins", "macros", and "scripts" is that they are indeed executable. Nothing says the malicious person coding these things is gonna follow the rules. He is free to code some really nasties in assembler if he so desires. The state of music file distribution I find really disturbing. We have an MP3 format which is generally well understood, yet it seems everybody jumping on the bandwagon wants to use proprietary formats which are not generally understood, leaving us all open to the risks resulting from ignorance.
As a public, we aren't helping much. We agree to any damn thing they print in the EULA. As a public, we should INSIST that if we are to be kept ignorant by law how something works, if that something does something malicious, then its maker should have full responsibility for the problems it generated.
Basically I am proposing a trade. If you want the protection of law to keep the public ignorant, then you waive indemnity.
We have a patent system and copyright system in place. Both were implemented on the concept that the work was to be in the open. Why aren't encrypted work also known as "trade secret" and not afforded protection by copyright or patent? Basically, any work encrypted would be considered a "trade secret", not in the open, hence not eligible for protection by the patent or copyright system at all? But to make this happen, its gonna take the will of a lot of people to pressure the legislators to enact this. Pressure as in "if you do not do this, start polishing your resume.".
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
IIRC, the goal of -T is not to prevent you from *ever* using tainted data; it was to prevent accidents: running shell scripts with insecure $PATH variables, etc.
Untainting a variable by extracting a subpattern usually means "I know what I'm doing: I promise that I'll extract a safe substring from this". (Whether the developer *actually* knows what they're doing is, sadly, not detectable by Perl).
(As for -T not affecting a list passed to exec()/system(): that does seem odd, but maybe there's some Larger Purpose to it that I don't get).
BTW: I think it would have been better if you explicitly had to invoke some function like untaint() or this_is_safe_to_use_in_shell_commands()... just to make you think about it.
But imperfect as it is, -T beats the pants off the alternative approach that most languages give you, which is "You're On Your Own, Sucka".
I'm a bloodsucking fiend! Look at my outfit!
The option to register global variables is off by default since PHP 4 and for a very good reason: it's potentially insecure, as you demonstrated, and it also creates very sloppy code. Ever tried to debug a program you haven't written that uses those? You get variables that have never been declared being used, and it can be a pain to determine where exactly they come from. From an included file? $_POST? $_GET? Then you can get conflicta and it becomes an horrible mess - I can't understand why register_globals is an option, much less why it was the *default*
Karma: Could be worse (could be raining)
Almost everything in this article only applies because of hacker languages like C and C++, which Linux and FreeBSD use for virtually everything. It is so easy to forget to double-check bounds, input format, pointers, and all the other usual suspects. It's bizarre how programmers will use these error-prone languages for marginal performance gains just because their ego and haxor status is on the line. Sure, the kernel and drivers need to be in C. Sure, a Java VM needs to be in C. Sure, C++ is a good langage for game engines. But almost nothing else should be written in C/C++.
Command-line type programs can be written in Java and statically compiled into small, low-memory, fairly fast programs. And the JVM overhead is has almost no affect on the larger programs. But you have to work really hard to put a security problem into a Java app instead of working really hard not to. And you get garbage collection, an awesome API, security, faster compiling, dynamic classloading/linking, easier coding, etc. People think Java takes a lot of memory, is slow, and ugly. But that's almost entirely because of the Swing GUI, which is not actually all bad. Replace with IBM's SWT and you'll see a dramatic difference.
Of course there are other languages besides Java that protect against security problems, but few that do so as completely and easily. If half the effort had been put into inplementing the Java APIs in open source as just on GTK/GTK+ then linux/bsd could do nothing for ten years and still be ahead of the rest.