From: Wade Maxfield <maxfield@ctelcom.net>> Many thanks to the moderator who pointed out errors and suggested the > correct information on this post. Over half the ideas are due to him. ;)> 1. Programs put data in local variables in functions. These variables > are on the computer stack. Feeding data to those variables (usually > string variables) causes the stack to be corrupt. Most often the > perpetrator will put code into the string buffer and put the return > address of the code in the string buffer into the correct location in the > stack. When the program exits ...When the function returns ...> In one case I saw, a perp deleted /etc/hosts.deny, ran adduser to create > user rewt, then telnetted into the system. /etc/hosts.deny is now "chattr > -i". What stopped the perp in that case was that /etc/skel/.bashrc had an > exit at the end of the script. He was immediately logged out and went > away. He was using the buffer overflow in named 4.9.6 to do it.Was that "chattr +i" ? What difference does it make against root ? What if he copied /bin/sh over tcpd and a daemon instead ? Imagine "telnet stream tcp nowait root /bin/sh /bin/sh", I may test this - it looks dangerous.> In the past, I have had a situation where a shell was running the > program, and the executable did a GPF. The shell was left standing > with a prompt, as the root user. In this case, the perp used the > open communication link to run commands as root.How was it called ?> A race condition can exist that can cause the daemon to copy or send a > file to the wrong location. A race condition is called that due to the > winner being the first one to win the "race." Basically, if your program > checks permissions and then decides to do something with the information > it gathered, then does it, it will be vunerable to a race.A fairly crude way of checking for this is at http://www.notatla.demon.co.uk/SOFTWARE/SCANNER/scanner-1.0b.tar.gz Better to think about how you write the code though.> To handle this, you must put in a lot of thought. Generally, a file > operation is a serial resource that is being used in a multitasking > environment. The traditional ways to deal with serial resources are 1) > use gatekeepers to enforce serial access to a serial resource, and 2) lock > the system down so that you own all of the cpu cycles until completion of > your operation on a serial resource, or 3) don't use the serial resource > at the multitasking level.Dropping privs from root to user for handling user files is good too.> To not use serial resources at the multitasking level, push them into > device drivers which run atomically. They are not interrupted (if they > disable interrupts) and can finish dealing with one request at a time.I wonder if this really helps with the original question.> You can also create a crc of your input file(s) while you can trust > them. Move your input files(s). Verify the crc still is the same on the > resulting output files.CRC is actually weak against deliberate modification. See the tripwire program for several stronger functions for this purpose. Look at ssh if concerned about IP spoofing. You might find you can avoid writing your program as a daemon if you use ssh to reach it.> 4. Denial of Service (DOS) attacks can be generated by sending the > wrong kind of data or a large amount of data to a TCP/IP daemon, > causing it to freeze on a port or zombie or become a runaway process > chewing up all cpu cycles. As the moderator pointed out, this stop > servicing of legitimate users.> If you must remain standing at all times, limit the number of daemons and > their duration. Put automatic reject mechanisms on information coming > from the same ip faster than a certain rate.Hashcash can be used to "charge" for connections so you can make the client use more computing power than the server. Anybody now trying to DoS your box by that method . It is used in my (usable but unfinished) http://www.notatla.demon.co.uk/SOFTWARE/angel.0.5.tar.gz -- ############################################################## # Antonomasia ant@notatla.demon.co.uk # # See http://www.notatla.demon.co.uk/ # ##############################################################
On Sat, 27 Nov 1999 22:42:21 GMT, Antonomasia <ant@notatla.demon.co.uk> wrote:>From: Wade Maxfield <maxfield@ctelcom.net> >> In one case I saw, a perp deleted /etc/hosts.deny, ran adduser to create >> user rewt, then telnetted into the system. /etc/hosts.deny is now "chattr >> -i". What stopped the perp in that case was that /etc/skel/.bashrc had an >> exit at the end of the script. He was immediately logged out and went >> away. He was using the buffer overflow in named 4.9.6 to do it. > >Was that "chattr +i" ? What difference does it make against root ?Multiple redundant security measures, even not entirely effective ones, can stop casual attackers. It would not stop someone who really wanted _your_ box. This comes down to the question of what you're trying to protect: do you want security enough to keep people out, no matter what the cost, or only enough to make people with short attention spans give up and move on to the next target? If you have an attacker who is determined enough to attack daemons with custom machine code (custom enough to cope with not having a /bin/sh, a telnetd or similar access protocol, chattred files everywhere, stripped down libc.so, and to figure out how to get all this through a restrictive firewall), then trivial measures such as /etc/hosts.deny won't help you. I have found from personal experience that most attackers who do penetrate a daemon are unable to cope with non-trivial routing and firewall rules afterwards, even though all this stuff can be controlled from the root account which they just compromised, and the configuration is not very complicated (basically two ethernet cards and IP masq is too hard for most intruders to understand, especially if eth0 is on the inside). It is very expensive to keep a determined attacker out of your machine. You would have to strip the box of anything that didn't contribute directly to functionality or security, and employ external measures such as code review (have you read your Linux kernel sources lately?), content-filtering firewalls, and dedicated human monitoring as well. -- I don't speak for Corel. zygob@corel.ca at work, zblaxell@furryterror.org at play. GPG-encrypted email preferred at zblaxell@feedme.hungrycats.org GPG fingerprint: 2B32 546D 21A5 0DB2 20C8 AF10 1D4A 610E 6972 2DEE GPG public key: http://www.hungrycats.org/~zblaxell/gpg-public.txt