Slashdot Mirror

How "passwd" works with root group r-- and no SUID is a mystery to me, I'll have to look later.

Please take a look at our presentation slides, it only takes a few minutes. Then you might have more specific questions on the implementation, which I'd be happy to answer.

http://www.openwall.com/tcb/
http://www.openwall.com/presentations/Owl/mgp00020.html
http://www.openwall.com/presentations/Owl/mgp00021.html
http://www.openwall.com/presentations/Owl/mgp00022.html
http://www.openwall.com/presentations/Owl/mgp00023.html

... he was more experienced than me ...

Please note that what I wrote in my reply to your comment was quite different. I never said anything about your experience. Now that you raised this topic, I can say that you appear to be familiar with Unix security. You simply had not looked at our stuff before you wrote your comment, that's all.

I find your comment re: the cost of PIE interesting, thanks! It leaves many questions, though. 6% on 32-bit x86 is the number I had been aware of before. Your statement that "the affected code was actually running less than 2% of the time" is curious and potentially very useful. However, this, assuming that it's true, does not yield your claimed 0.0012%; it yields 0.12%. Of course, 0.12% may be considered acceptable (far more likely than 6% at least). I am curious about the details of your test; I guess, some systems will actually run "the affected code" 100% of the time - e.g., this happens if I build John the Ripper as PIE and run it for days (which is why I dislike Gentoo building JtR like that, and have to recommend JtR users to make their own builds). ;-) I'd appreciate it if you e-mail me (solar at openwall.com) more details on your test, and we'll discuss from there. We're considering PIE by default for post-3.0 Owl-current (and next release).

Your comments about cron/at are similar to what we thought of when we designed the system. Just like our per-user shadow files, the crontab files are per-user (and they were prior to our changes as well). Our crond does check crontab file ownership, and then it will only run the cron jobs found in the file as the file's owner. Cron and at jobs running as root are supported - of course, as long as the corresponding files are root-owned.

From some googling and the announcement.

Basically if you exploit something with 'shadow' (i.e. passwd) you add a root user account to /etc/passwd and su to it. if you exploit crontab or at, you add a crontab that adds a root level account or runs a command as root or creates a SUID program. It requires some hacker creativity, but doesn't make anything secure.

That's poor analysis on your part, so your conclusion is completely wrong. Please refer to our presentation slides for an explanation of how things actually work and why the attacks you describe would not work:

http://www.openwall.com/presentations/Owl/

BTW, the announcement specifically mentioned that "a vulnerability in crontab(1) or at(1) can't result in a root compromise without a vulnerability in crond(8) or in a critical system component relied upon by crond(8)." Did you not read that? Or do you disagree, thereby stating that we're inexperienced in the stuff we've been doing for 10 years?

Since a lot of people are confused just like you are, I'd be happy for any suggestions on how we could explain what we do and what we have achieved better. I did include that quote in the announcement specifically because I knew of common misconceptions about our work, but apparently that was not enough? Thanks!

The new system allows /bin/su to have permission to write to /etc/passwd, but not to do other root things like read/write to /root or mount filesystems not enumerated in /etc/fstab. It is "granular root".

You're talking of Fedora's approach with fscaps (and there are errors in your description). We don't do that. We're smarter than that! So your comment does not apply to Owl, at all. I've explained what we actually do in further comments. It is also shown in our presentation slides:

http://www.openwall.com/presentations/Owl/

Specifically:

http://www.openwall.com/presentations/Owl/mgp00013.html
http://www.openwall.com/presentations/Owl/mgp00020.html

(and further slides, just click "next").

The new system allows /bin/su to have permission to write to /etc/passwd, but not to do other root things like read/write to /root or mount filesystems not enumerated in /etc/fstab. It is "granular root".

You're talking of Fedora's approach with fscaps (and there are errors in your description). We don't do that. We're smarter than that! So your comment does not apply to Owl, at all. I've explained what we actually do in further comments. It is also shown in our presentation slides:

http://www.openwall.com/presentations/Owl/

Specifically:

http://www.openwall.com/presentations/Owl/mgp00013.html
http://www.openwall.com/presentations/Owl/mgp00020.html

(and further slides, just click "next").

The new system allows /bin/su to have permission to write to /etc/passwd, but not to do other root things like read/write to /root or mount filesystems not enumerated in /etc/fstab. It is "granular root".

You're talking of Fedora's approach with fscaps (and there are errors in your description). We don't do that. We're smarter than that! So your comment does not apply to Owl, at all. I've explained what we actually do in further comments. It is also shown in our presentation slides:

http://www.openwall.com/presentations/Owl/

Specifically:

http://www.openwall.com/presentations/Owl/mgp00013.html
http://www.openwall.com/presentations/Owl/mgp00020.html

(and further slides, just click "next").

No, Fedora are using a different approach. We do not replace SUID/SGID with capabilities, instead we carefully design the system to take advantage of the standard Un*x OS level permissions. JFYI, all this buzz with replacing SUID/SGID binaries emerged from the recently discovered vulnerability (BTW, Owl was among few distributions which wasn't affected by that vulnerability at all), but unfortunately people are often getting things wrong, when it comes to security. Please review the following message that describes some pitfalls along Fedora or Ubuntu's ways: http://www.openwall.com/lists/oss-security/2010/11/08/3 .

Yes, our distro doesn't encourage users to use su or sudo. The reason is that escalating privileges from a less privileged account to a more privileged account is bad from security standpoint. I found the following message in our mailing list. In this message Solar Designer explains the issue with su/sudo: http://www.openwall.com/lists/owl-users/2004/10/20/6 An excerpt from the above message: "Presently, the only safe use for su is to switch from a more privileged account to a less privileged one (whenever this distinction can be made) in a non-interactive script (without a tty). As soon as a tty is used, there is a security problem. As soon as you su to a more privileged account, there is another security problem." I hope you'd find this useful.

http://www.openwall.com/Owl/ARCHITECTURES.shtml
> Cross-builds are not supported: it is not possible to build packages for an architecture different than that of the build host, nor for a flavor of the architecture newer than that implemented in the build host's CPU.

No, it can't do cross-compiling. And ARM is not supported.

I'm not sure I believe that. The only way I can think of permitting things like su and passwd (among many others) is by running some sort of permissions escalation daemon ("owl-control" perhaps?) as root that essentially does the same thing. This moves the vulnerability from the binary to the permissions daemon.

There is almost no documentation on owl-control; the best I could find was a FreeBSD port and the (encoded) man page as plucked from CVS HEAD.

If this has been independently audited and continues to appear to be a Good Idea then perhaps it would be of interest to one of the larger distributions?

I suppose you also think salted passwords are snake oil? Sure, they're not going to stop someone who's brute forcing on-the-fly, but it does make life more complicated for people using rainbow tables.

I only mention salted passwords because Wordpress uses them (see wp-includes/class-phpass.php).

When the submitter referenced "open source alternatives that go by similar names", he was referring to ophcrack. Similar features are also available from Cain and Abel, and John the Ripper.

I maintain a list of top password crackers and sniffers as part of my SecTools.Org site.

While the submitter is correct that they have much more competition now, I still wish to congratulate the former L0pht guys on the new release!

What a stupid summary. There's absolutely nothing wrong with password resetting. The problem is password security questions or password "hints" or whatever they're called. Whenever I encounter those, I pound on my keyboard until the text field's maximum length is reached, hoping that's sufficiently random and long enough to thwart any brute force or crib-based attacks. It's so bad sometimes that not only do sites require you enter this information, but they also have ridiculously asinine limits on maximum password length and question/answer length. It doesn't matter whether you choose a strong password, if that can be broken by something as insanely weak as an honest answer to one of the 'security questions' that you're provided with on most sites (though some sites let you specify a custom question). Whoever thought up that one was not the brightest crayon in the box, and has no business doing anything with security applications. They may have had the best of intentions, but took a lot of the ideas they've heard from the security field and applied them poorly, which is why you only let EXPERTS design security applications. This is a lot of theater and nothing more, and poor implementation is the classic amateur mistake.

These are the same people who put plain-text passwords in a database or text file and let you "retrieve" your password which they've conveniently stored, unaltered. Sometimes, if they want to feel really clever about themselves, they might upgrade to un-salted MD5. Yay. There needs to be an industry standard system for web applications, or whatever else, designed by someone who knows what they're doing. Don't roll your own security suite. You're most likely not smart enough, even if you think you are. I use Solar Designer's phpass for cryptographic hashing in my web applications, and he has several other good pieces of software that are relevant to the topic.

The process I use for password resets goes like this (starting from the very beginning):

1. user goes to the registration page for my website
2. the user is given guidelines on password strength, but these aren't enforced, because it's their own ass if their account gets compromised (though, if there were any risk to said compromisation, then I would impose strengthening measures)
3. the user provides an e-mail address which must be legitimate (I'm not too keen on this myself, since it's none of my business what anyone's e-mail is, and sites requiring e-mail for registration are annoying, but, if you want any semblance of security, this is probably the way to go)
4. in the back end, the user's plain-text password is converted to salted MD5 or bcrypt (bcrypt for Linux; bcrypt is native to OpenBSD and Openwall Linux) through UNIX crypt()
5. the account is not activated until the user visits a link sent to their inbox, based on a cryptographically secure random confirmation ID (20 bits SHA1)
6. the user forgets his password
7. the user visits the password reset page on my website, inputs their e-mail, and clicks reset
8. a confirmation e-mail is sent to the address on file, complete with a link to a web page on my site with a secure cryptographically generated IP as a GET variable (20 bits SHA1); no password is generated until the link is clicked (or typed in, which I would prefer to clicking, and I don't render e-mail in HTML anyway)
9. once the link is visited, an alternate password is creating using a secure, properly designed and developed cryptographically strong password generation library
10. upon logging in with the new, cryptographically strong password, the old password is deactivated and can no longer be used for logging in

That system is not infallible, but it doesn't require weakening the concept of a password-based system (when such a system is already, inherently, an absurdly flawed and very primitive idea).

What a stupid summary. There's absolutely nothing wrong with password resetting. The problem is password security questions or password "hints" or whatever they're called. Whenever I encounter those, I pound on my keyboard until the text field's maximum length is reached, hoping that's sufficiently random and long enough to thwart any brute force or crib-based attacks. It's so bad sometimes that not only do sites require you enter this information, but they also have ridiculously asinine limits on maximum password length and question/answer length. It doesn't matter whether you choose a strong password, if that can be broken by something as insanely weak as an honest answer to one of the 'security questions' that you're provided with on most sites (though some sites let you specify a custom question). Whoever thought up that one was not the brightest crayon in the box, and has no business doing anything with security applications. They may have had the best of intentions, but took a lot of the ideas they've heard from the security field and applied them poorly, which is why you only let EXPERTS design security applications. This is a lot of theater and nothing more, and poor implementation is the classic amateur mistake.

These are the same people who put plain-text passwords in a database or text file and let you "retrieve" your password which they've conveniently stored, unaltered. Sometimes, if they want to feel really clever about themselves, they might upgrade to un-salted MD5. Yay. There needs to be an industry standard system for web applications, or whatever else, designed by someone who knows what they're doing. Don't roll your own security suite. You're most likely not smart enough, even if you think you are. I use Solar Designer's phpass for cryptographic hashing in my web applications, and he has several other good pieces of software that are relevant to the topic.

The process I use for password resets goes like this (starting from the very beginning):

1. user goes to the registration page for my website
2. the user is given guidelines on password strength, but these aren't enforced, because it's their own ass if their account gets compromised (though, if there were any risk to said compromisation, then I would impose strengthening measures)
3. the user provides an e-mail address which must be legitimate (I'm not too keen on this myself, since it's none of my business what anyone's e-mail is, and sites requiring e-mail for registration are annoying, but, if you want any semblance of security, this is probably the way to go)
4. in the back end, the user's plain-text password is converted to salted MD5 or bcrypt (bcrypt for Linux; bcrypt is native to OpenBSD and Openwall Linux) through UNIX crypt()
5. the account is not activated until the user visits a link sent to their inbox, based on a cryptographically secure random confirmation ID (20 bits SHA1)
6. the user forgets his password
7. the user visits the password reset page on my website, inputs their e-mail, and clicks reset
8. a confirmation e-mail is sent to the address on file, complete with a link to a web page on my site with a secure cryptographically generated IP as a GET variable (20 bits SHA1); no password is generated until the link is clicked (or typed in, which I would prefer to clicking, and I don't render e-mail in HTML anyway)
9. once the link is visited, an alternate password is creating using a secure, properly designed and developed cryptographically strong password generation library
10. upon logging in with the new, cryptographically strong password, the old password is deactivated and can no longer be used for logging in

That system is not infallible, but it doesn't require weakening the concept of a password-based system (when such a system is already, inherently, an absurdly flawed and very primitive idea).

Why not simply run John the Ripper with a small dictionary and the --stdout option? That will produce a list of names that look like real candidates and operate at great speed without depleting your entropy pool.

Not that I advocate it—it's a silly and possibly harmful exercise, IMHO. I'm just saying.

Really?
Any cracker worth his salt will have a boot disk or two at hand, especially if he's gained physical access to a machine. Cracking a Windows machine is trivial - I've reset the password on a few boxes myself for those that have forgotten their passwords, and it was dead simple, believe it or not...

This is how so many idiots in the world think "P@$sW0rD" is a strong password...

The article you linked to isn't the worst I've seen. But they still recommend replacing S with $ and ( with C. Making these simple character substitutions adds little/no extra strength to your password. Password crackers know to look for these substitutions (and can apply them to entire dictionaries).

Even more interesting is what happens when you start looking at letter frequencies. People are more likely to use "a" in a password than "z" and are more likely to follow "s" with a "h" rather than a "q".

Have a look at John the Ripper. When you tell it to brute force passwords it doesn't crack from aaaaaaaa through to ZZZZZZZZ. It has advanced rules which deal with letter frequencies and other interesting probabilities.

The only secure password is no "password". Use digital certificates/PKI instead. The reason is that private keys are randomly generated and have 8 bits of entropy per byte. Passwords on the other hand have a limited character set and therefore have between 1-3 bits of entropy per byte (most passwords are 2). And this assumes the passwords are generated randomly based on those character sets. To recreate the security of a randomly generated 256bit key (32 bytes) using traditional passwords, you'd need a password of more than 128 characters in length!

What I find even more amusing is the use of passwords in encryption schemes. You might be using 256bit encryption keys - which are generated from your password with well under half the entropy of the random 256bit key. Crackers aren't going to try cracking the derived 256bit key - they're going to attack your weak little password. Or more likely, they'll use a keylogger or another "thinking outside the square" method to retrieve your password.

>john-mmx iphone.pwd
Loaded 2 password hashes with 2 different salts (Traditional DES [64/64 BS MMX])

alpine (mobile)
dottie (root)
guesses: 2 time: 0:00:00:31 (3) c/s: 685650 trying: dewMso - dotty1

mobile password was gotten instantly (in first second)
30secs using john the ripper with no special word files or anything.

http://www.openwall.com/john/

It's not a document, but nothing convinces people more than having their passwords cracked. Run John the Ripper http://www.openwall.com/john/ or something like that on their accounts. They'll understand it's a real risk.

It does, indeed, depend upon the application. However, for password hashing, I would recommend bcrypt. OpenBSD implements this in its passwording scheme, and, on the Linux front, there's Openwall GNU/*/Linux. Solar Designer also has what might be needed for application implementation here: http://www.openwall.com/crypt/

It does, indeed, depend upon the application. However, for password hashing, I would recommend bcrypt. OpenBSD implements this in its passwording scheme, and, on the Linux front, there's Openwall GNU/*/Linux. Solar Designer also has what might be needed for application implementation here: http://www.openwall.com/crypt/

Interesting that Debian seems to know that passwords were "weak". Only 1 poster here seems to have picked up on that curiosity. How do they know after the fact that a password was weak?

Cracking passwords when you have access to the non-reversible hashed versions of the passwords (aka "/etc/shadow") can be trivially easy on modern hardware, when using a tool such as John the Ripper, or, if you have a lot of spare harddrive space (and RAM), RainbowCrack. If this box was using md5 hashes (most likely), JTR on modern hardware can easily crack 8,000+ passwords a second, which, when combined with advanced password guessing techniques, will most likely find weak passwords within an hour or two.

John the Ripper most likely. Great tool - recovered the root password for a SGI box a friend bought on eBay in less than a second (your password may vary.)

John the Ripper
http://www.openwall.com/john/

And comparing with OWL (Openwall Linux) as well. http://www.openwall.com/Owl/

Well... here and here off the top of my head.

There's no doubt that running a secure OS and adhering to good practices (such as never do anything as root that doesn't have to be done by root) is increasingly important these days. One client I work with is running Openwall and it seems to be a good solution. There are many other security enhanced Linix possibilities, too, as well as OpenBSD - which I don't have direct experience with, but I hear it's pretty tight.

At home, I just keep up-to-date with Debian and practice careful management, but for any corporate systems, I'd start with a secure OS.

Speaking of which, why is it said not to login as root over SSH? The only plausible reason I've ever heard is that the encryption is stronger after the login is complete, so your root password is safer if you 'su' to root after logging into another account.

I think it may be due to an old vulnerability. In versions of OpenSSH earlier than 2.5, you can discover the length of the password using traffic analysis. Basically you look for the following sequence of packets:

C: 1 packet (s)
S: 1 packet (echo s)
C: 1 packet (u)
S: 1 packet (echo u)
C: 1 packet (newline)
S: 1 packet (echo newline)
S: 10 packets ("Password: ")
C: x packets (the password)
C: 1 packet (newline)
S: 1 packet (echo newline)

This technique worked for both SSH-1 and SSH-2 protocols. For more detail, (and a better, more accurate description of how the vulnerability worked) you can read the original security advisory.

Another problem with logging in directly as root is that you no longer can audit who is logging in as root in an environment where multiple users have root access.

http://the1.no-ip.com/~the1/johnbench.txt

You can download the john the ripper source code here:

http://www.openwall.com//john/

and then build it and run your own tests.

There are those who prefer BIND 4 to BIND8 or 9, for various reasons.

There ARE somewhat secure/patched versions of BIND4 out there, notably Openwall'spatched version.

OpenBSD had a patched version of BIND 4 until a few distributions ago.

Anyways, it's funny to see that DNS Cache poisoning is still happening today. This was so 1990s.

I've never any problems using djbdns.

Microsoft calls for password replacement because of "precomputed hash tables"? This very amusing, because it is pretty much only Microsoft who is vulnerable to these attacks. Why? they store only the hash of the password. Because there is a (nearly) one-to-one correspondance between password and hash, attackers can build up tables of precomputed hashes and use these to directly look up the passwords.

Everybody else mixes random salt bytes into passwords prior to hashing. Unix was doing this over 20 years ago. Modern systems use long (16+ character) salts that make precomputed hash tables infeasible for many years to come.

Some platforms use a better system still, that makes it more difficult for password guessers now and well into the future.

The only intrinsic problem with passwords is that people choose dumb ones, but again this can easily be fixed with a little technology

Here's a basic roundup of useful links:

• GRsecurity
• CIS Scan
• Openwall Project
• Bastille
• RSBAC
• SELinux

See http://www.openwall.com/advisories/OW-002-netscape -jpeg/.

OK, um.

(1) The IJG implementation is what I refer to as "libjpeg". I realize now that I spoke without really knowing what I was talking about, and probably shouldn't have made that post.

(2) However, I have yet to see any evidence that libjpeg actually had a flaw. When Netscape supposedly had the "same flaw", it was NOT in libjpeg's code, but in a piece of code they added. If you read this link in detail, you find this (emphasis mine):

"Netscape browsers use the Independent JPEG Group's decoder library for JPEG File Interchange Format (JFIF) files. However, they install a custom handler for processing the COM (comment) marker that stores the comment in memory rather than just skip it like the library would do. Unfortunately, the new handler doesn't check whether the length field is valid, and subtracts 2 from the encoded length to calculate the length of the comment itself. It then allocates memory for the comment (with one additional byte for its NUL termination) and goes into a loop to read the comment into that memory."

Microsoft apparently later made the same modification with the same mistake, being an easy mistake to make. Can you quote me any source that actually says libjpeg itself has a security hole?

In fact, several years ago Netscape/Mozilla had the exact same bug! MS and Moz made the exact same error. It's an easy one to make.

Presumably the exploit would need to be different for Mozilla though, even if the bug did still exist. It's things like the shell: exploit that apply to Mozilla AND IE that really worry me. IE's a big, tempting target and Mozilla could get caught in the crossfire.

(from link)

+++ mozilla/modules/libimg/jpgcom/jpeg.cpp Wed May 24 17:24:03 2000

they managed to patch this four years before microsoft? and microsoft knew they were using the same IJG codebase?

The openwall page says that the vulnerability in Netscape's copy of the IJG code was in a Netscape modification to the code, not in the base code. So was there another vulnerability in the IJG code (meaning that everyone else inherited it, too), or did Microsoft introduce their own vulnerability with one of their own mods?

As another poster earlier in the thread mentioned, Microsoft were hardly the only ones doing this. Netscape/Mozilla were also affected.

Indeed, Netscape, which also uses that code for its JPEG decoding had that flaw (but it was fixed earlier, and of course, it did not make the news nearly as much as this Microsoft issue, owing to its much smaller market share.)

http://www.openwall.com/advisories/OW-002-netscape -jpeg/

Because the JPEG COM field length variable is 2 bytes wide, and itself is included in the length value, the minimum value for this field is 2, this implies an empty comment. If the comment length value is set to 1 or 0, a buffer overflow occurs overwriting heap management structures.

The problem is GDIPlus normalizes the COM length prior to checking it's value; a starting length of 0 becomes -2 after normalization (0xFFFE unsigned), this value is converted to the 32 bit value 0xFFFFFFFE and is eventually passed on to memcpy which attempts to copy ~4G bytes into heap memory.

Indeed, Netscape, which also uses that code for its JPEG decoding had that flaw (but it was fixed earlier, and of course, it did not make the news nearly as much as this Microsoft issue, owing to its much smaller market share.)

http://www.openwall.com/advisories/OW-002-netscape -jpeg/

Hopefully, your password hashes are properly hidden, and you are using something like MD5.

If the answer is you are using crypt(3), and the hashes are user visible, they you are in trouble. Crypt(3) is dead, as far as I am concerned. It only allows up to 8 character passwords, and is far too vulnerable to cracking on modern hardware. I wrote a paper for class back in 1997 on brute forcing crypt(3) using easily available software. Since I wrote that paper, cracking speeds have increased over 50-fold. Given a dozen 3GHz P4's (say a small computer lab), I can brute force all possible lowercase alphanumeric passwords in a little over 4 days. Mixed case would take longer, a week for 7 character and under passwords, and a bit less than a year for 8 character passwords. If I had access to a cluster, or a group of 0wned machines, it could still be done in a reasonable timeframe.

If the answer is you are using old-style NT LanMan passwords that someone can get a copy of, you are screwed. They use no salt, are uppercase only, and the entire keyspace can be brute forced like butter. The password is split into two 7 character halves, which can be cracked independently. If you have a machine running Samba, you can find these in the smbpasswd file. On NT/2000, they are still used if you have Windows 95/98 clients on your network. You have to extract them from the SAM using PWDUMP or the like.

If anyone wants to try cracking his or her own password, I suggest getting John the Ripper.

How exactly do you stop the cpu executing the stack if there is no way to mark it as non-executable?

...John the Ripper. It's been ported to cracking so many password systems. Very useful in telling someone that their dog's name is not a valid password. The upside of it is that you crack passwords on your own network for your benefit, and not expose them to masses of other people.

There are already md5 cracking utilities out there that are extremely fast.

John the Ripper has been around for ages. Simple, easy, and pretty configurable.

Now, distributed md5 cracking would be quite interesting.

Find out for yourself: Distributed John Needs work, but worth playing with.

It'd probably be faster to brute force the hash on your own machine, really.

If you're using a small character set using an incrimental cracking method on passwords, around 7 or less in length, sure. But, of course, it's an exponential increase in time for each new length and goes from minutes to months in no time with one cpu.

You have access to the shadow file, but you can't remember your password, so what do you do?

Submit the hashes over the internet of course!!

What the hell were these people thinking? If you have access to the shadow file, then you have root access, and you can just passwd a different password. Root doesn't have to supply the current password.

Worst case scenario, just cut out the hash and it'll be a blank password until you reset it. And if you really need that password, odds are that the others in there would be a nice bonus too, in which case there's plenty of other tools available.

Solar Designer released the Openwall patch to kernel 2.4.26 on April 17th, three days after the kernel itself was released. That's pretty active maintainance if not development of new features. I like it because it tends to be more conservative than many other security patches out there.

Unlike a comprehenive top to bottom system like Gsecurity, the Openwall Project is more of a collection of very useful patches and utilities. Their kernel patches are superb. The Openwall project is a good place to get your feet wet without having to devote a lot of time to a learning curve. Good bang-for-the-buck, so to speak.

Too bad! It was only last week that I heard that Grsecurity was so promising and more actively delevoped than, for example, Openwall

• Abiword - Word processor, supports .doc, .rtf, GPL.
• Open Office - Whole Office suite, including a database frontend and BASIC macro language.
• Perl - Scripting language
• Python - Scripting language
• Cygwin - UNIX emulator. Can create Windows programs, reliant on a cygwin1.dll.
• MinGW - Port of some of the UNIX utilities (BASH, gcc, vi...) to Windows.
• djgpp - UNIX emulator for DOS.
• Mozilla, Firefox, Thunderbird - Web browser, e-mail client, IRC client, lots more.
• Filezilla - FTP client.
• xchat - IRC client.
• putty, pscp, psftp and others - Telnet/SSH clients.
• Gaim - Client for IRC/Yahoo/MSN/ICQ/AIM and more.
• gzip - Compression (usually better than .zip).
• tar - Extracts/Makes tar archives.
• bzip2 - Totally ace compression (usually better than gzip).
• Info-ZIP - Support for .zip. Good free substitute for Winzip.
• 7-zip - Support for multiple compression formats.
• frhed - Hex editor
• Ext2fs - Several programs for doing Ext2 under Windows.
• Antiword - Converts documents out of the proprietary .doc format.
• MySQL - RDBMS.
• Apache - Web/Proxy server
• sendmail - Mail server
• squid - Proxy server
• freeamp - Audio player
• winlame - MP3 encoder
• cd-ex - MP3/OGG encoder?
• gimp - Very detailed graphics program.
• imagemagick - Graphic manipulation. Provides the 'convert' utility under UNIX.
• freeciv - Civilisation clone.
• gnuplot - Plotting package.
• TightVNC - A fork of VNC, with enhancements.
• RealVNC - The original VNC.
• rdesktop - Access Windows Terminal Services and Remote Desktops.
• Nmap - Well known port scanner.
• John the Ripper - Password cracker. Does NT and MD5.