| Related sites for http://www.canonical.org/~kragen/security-holes.html |
| Calibri_Research CalibriTM-133, is a ready to use, compact multipurpose network appliance with embedded Linux OS. Offering an efficient and low cost solution to firewall, VPN and routing demands. | | Clear_Technologies Customer Relationship Management (CRM) software paired with IBM Series computers for mid-size companies that provides integrated sales, marketing and customer service functions. | | Fields_Data_Recovery_USA Offer data Recovery solution worldwide and free evaluation on all media including hard drives, RAID systems and all optical media. | | Alloyant_Technologies Makers of the Armor Firewall appliance. Provides information on its OpenBSD-based product which offers remote administration, tight security, Web content filtering, and access control with list-based | | FactSet_Research_Systems Supplier of market data and economic information to the investment management and banking industries. | | RFC_1178 Choosing a Name for Your Computer. D. Libes. August 1990. | | RFC_1193 Client Requirements for Real-Time Communication Services. D. Ferrari. November 1990. | | Pathbuddy Easily change to predefined folders in the Windows file Explorer and in 'Open' and 'Save' dialogs with hotkeys or through a browseable list. | | FerretTronics FerretTronics is a leading supplier of chips and software designed to control RC servos, stepper motors and other electronics and robotics products. | | PC_Pro_-_Twenty_Years_of_the_Mac A look at the past, and future, of the Mac. (Free registration required) (January 5, 2004) | | Basic_Tutorial Peter van Tilburg and Roger Schmitz, librarians at Tilburg University, developed a free online tutorial on searching the Web. Target group: novice college students. | | Blackstrobe_Studio Links to free VST / VSTi effects, instruments, manuals, and studio resources. | | Progland_com Provide different types of Perl CGI implementation, including script customization, new script programming and script installation. | | TypePad Service for hosting and publishing weblogs and photo albums. | | Data_Business CD duplication and replication services. CD printers, recordable CD and CD duplicator and diskette duplication services. | | Mail_Validator Verifies email addresses are deliverable in an email list. | | Jordan,_Victoria Offers site design, graphics, hosting and maintenance. Located in Wilbraham, Massachusetts. | | New_York_Public_Library_Style_Guide Offers guidelines and downloadable style sheets. | | Worldwide_Computers Offers design, hosting assistance, and maintenance services. | | Creative_Think_Tank,_The Offers design, eCommerce, marketing, and e-Business services. |
|
How to find security holesBody text last updated 1998-07-22. Recently has become the most popular page of mine, presumably because a bunch of lamers want to learn how to break into things. This isn't really the focus of this document; I wrote it as a primer for people participating in the Linux Security Audit project, which is intended to find security holes so they can be fixed before people use them to break into things.I wouldn't be surprised if calling 100-200 people a day `lamers' results in electronic attacks on me or my machine (kragen.dnaco.net.) All I can say is that people who do this would thereby demonstrate their lamosity.These paragraphs added 1999-02-26. How to find security holes Note: I haven't found any security holes, so take thiswith a pillar of salt. Also, this document is poorlyorganized. Suggestions for better organization andterminology are welcomedwith open arms. Reports of any errors are urgentlyneeded.If a program has a bug in it that manifests underextreme circumstances, then normally,it's a minor annoyance. Usually, you can just avoidthe extreme circumstances, and the bug isn't a problem.You could duplicate the effect of tickling the bugby writing your own program, if you wanted to.But sometimes programs sit on security boundaries. Theytake input from other programs that don't have the sameaccess that they do.Some examples: your mailreader takes input from anyoneyou get mail from, and it has access to your display,which they probably don't. The TCP/IP stack of anycomputer connected to the Internet takes input from anyoneon the Internet, and usually has access to everything onthe computer, which most people on the Internet certainlydon't.Any program that does such things has to be careful. Ifit has any bugs in it, it could potentially end up allowingother people -- untrusted people -- to do things they'renot allowed to do. A bug that has this property is calleda "hole", or more formally, a "vulnerability".Here are some common categories of holes. Psychological problems When you're writing a normal piece of software, your purposeis to make certain things possible, if the user does thingscorrectly. When you're writing a security-sensitive pieceof software, you also have to make certain things impossible,no matter what any untrusted user does. This means thatcertain parts of your program must function properly under awide range of circumstances.Cryptologists and real-time programmers are familiar with doing things this way. Most other programmers aren't, and habits of mind from theirnormal-software work tend to make their software insecure. Change of role hole A lot of holes come from running programs in differentenvironments. What was originally a minor annoyance -- orsometimes even a convenience -- becomes a security hole.For example, suppose you have a PostScript interpreter thatwas originally intended to let you preview your documentsbefore printing them. This is not a security-sensitive role;the PostScript interpreter doesn't have any capabilities thatyou don't. But suppose you start using it to view documentsfrom other people, people you don't know, even untrustworthypeople. Suddenly, the presence of PostScript's file accessoperators becomes a threat! Someone can send you a documentwhich will delete all your files -- or possibly stash copies of your files someplace they can get at them.This is the source of the vulnerabilities in most Unixes' TCP/IPstacks -- they were developed on a network where essentiallyeveryone on the network was trustworthy, and now they're deployedon a network where there are many people who aren't.This is also the problem with Sendmail. Until it went throughan audit, it was a constant source of holes.At a more subtle level, functions that are perfectly safewhen they don't cross trust boundaries can be a disaster whenthey do. gets() is a perfect example. If you use gets() in asituation where you control the input, you just provide a bufferbigger than anything you expect to input, and you're fine.If you accidentally crash the program by giving it too muchinput, the fix is "don't do that" -- or maybe expand the bufferand recompile.But when the data is coming from an untrusted source, gets() canoverflow the buffer and cause the program to do literally anything.Crashing is the most common result, but you can often carefully craft data that will cause the program to run it as executable code.Which brings us to . . . Buffer-overflow holes A buffer overflow occurs when you write a string (usually a stringof characters) into an array, and keep on writing past the end ofthe array, overwriting whatever happened to be after the array.Security-problem buffer-overflows can arise in several situations: when reading input directly into a buffer; when copying input from a large buffer to a smaller one; when doing other processing of input into a string buffer.Remember, it's not a security hole if the input is already trusted --it's just a potential annoyance.This is particularly nasty in most Unix environments; if the arrayis a local variable in some function, it's likely that the returnaddress is somewhere after it on the stack. This seems to be thefashionable hole to exploit; thousands and thousands of holes ofthis nature have been found in the last couple of years.Even buffers in other places can sometimes be overflowed to producesecurity holes -- particularly if they're near function pointersor credential information.Things to look for: dangerous functions without any bounds-checking: strcpy, strlen, strcat, sprintf, gets; dangerous functions with bounds-checking: strncpy, snprintf -- some of these will neglect to write a NULL at the end of a string, which can result in later copying of the result to include other data -- possibly sensitive data -- and possibly crashing the program; this problem does not exist with strncat, and I'm not clear on whether it exists in snprintf, but it definitely exists with strncpy; misuse of strncat, which can result in writing a null byte one past the end of the array; security-sensitive programs crashing -- any crash comes from a pointer bug, and perhaps the majority of pointer bugs in production code are from buffer overflows. Try feeding security-sensitive programs big inputs -- in environment variables (if environment variables are untrusted), in command-line parameters (if command-line parameters are untrusted), in untrusted files they read, on untrusted network connections. If they parse input into chunks, try making some of the chunks enormous. Watch for crashes. If you see crashes, see if the address at which the program crashed looks like a piece of your input. incorrect bounds-checking. If the bounds-checking is scattered through hundreds of lines of code, instead of being centralized in two or three places, there's an extremely good chance that some of it is wrong.A blanket solution is to compile all security-sensitive programs withbounds-checking enabled.The first work I know of on bounds-checking for gcc was done by RichardW. M. Jones and Paul Kelly, and is athttp://www.doc.ic.ac.uk/~phjk/BoundsChecking.html.Greg McGary mailto:gkm@eng.ascend.com did some other work. Announcement:http://www.cygnus.com/ml/egcs/1998-May/0073.html.Richard Jones and Herman ten Brugge did other work. Announcement:http://www.cygnus.com/ml/egcs/1998-May/0557.html.Greg compares different approaches inhttp://www.cygnus.com/ml/egcs/1998-May/0559.html. Confused deputies When you give a filename to a regular program to open, the programasks the OS to open the file. Since the program is running withyour privileges, if you're not supposed to be able to open the file,the OS refuses. No problem.But if you give a filename to a security-sensitive program -- aCGI script, a setuid program, a setgid program, any network server --it can't necessarily rely on the OS's built-in automatic protections.That's because it can do some things you can't. In the case of aweb server, what it can do that you can't may be pretty minimal, butit's likely that it can at least read some files with private info.Most such programs do some kind of checking on the data they receive.They often fall into one of several pitfalls: They check it in a time-dependent fashion that you can race. Ifa program first stat()s a file to see if you have permission towrite it, and then (assuming you do) open()s it, it's possible youmight be able to change the file to be something you don't havepermission to write to in the meantime. (One possible solution isto stat() or lstat() the file before opening it, open it in anondestructive fashion, then fstat() the open fd, then compare tosee if you've got the same file you stat()ed. Credit Eric Allman,via Keith Bostic and BUGTRAQ.) They check it by parsing the filename, but they parse the filenamedifferently than the OS. This has been a problem with lots of MicrosoftOS web servers; the OS does some fairly sophisticated parsing on thefilename to figure out what file it's actually referencing. Web serverslook at the filename to determine what kind of access you have to it;often, you have access to run particular types of file (based on filename parsing), but not to read them. If the default access lets you read a file, then changingthe filename so that the web server thinks it's a different kind offile, but the OS parses the filename to point to the same file, will give you the ability to read the file.This is a double-parsing problem, which we'll get into later, andalso stems from fail-openness. They check it in an extremely complex way that has holes in it,due to the original author not understanding the program. They don't bother to check it at all, which is rather common. They check it in a simple way that has holes in it. For example,many older Unix web servers would let you download any file in someone's public_html directory (unless the OS barred them). Butif you made a symlink or hardlink to someone else's private files,it was possible to download them if the web server had permissionto do so.At any rate, programs that have privileges you don't usually failto limit what they do on your behalf to just what they're supposedto do. setfsuid(), setreuid(), etc., can help.Another problem is that frequently, standard libraries look inenvironment variables for files to open, and aren't smart enoughto drop privileges while doing this. (Really, they can't be.)So we're forced to resort to parsing the filename to see if itlooks reasonable.Some OSes dump core with the wrong privileges, too, and if youcan make a setuid program crash, you can overwrite a file thatthe program's owner would be able to overwrite. (Dumping corewith the user's privileges often results in the user being ableto read data from the core file that they wouldn't be able toread normally.) Fail-openness Most security-sensitive systems fail to do the right thing undersome circumstances. They can fail in two different ways: They can allow access when they shouldn't; this is called fail-open. They can refuse access when they shouldn't; this is called fail-closed.As an example, an electronic door lock that locks the door by holdingit closed with a massive electromagnet is fail-open when the powergoes out -- when the electromagnet has no power, the door will openeasily. An electronic door lock that locks the door with aspring-loaded deadbolt that is pulled out of the way with a solenoidis fail-closed -- when the solenoid has no power, it's impossibleto pull back the deadbolt.CGI scripts commonly execute other programs, passing them user dataon their command lines. In order to avoid having this data interpretedby the shell (on a Unix system) as instructions to execute otherprograms, access other files, etc., the CGI script removes unusualcharacters -- things like ' |
|
