Immutable Security

Prior to Windows Vista, Microsoft’s default posture in Windows was to let the user have admin rights. That meant that not only did the user have admin rights, but so did the malware when it took advantage of one of the several juicy Windows vulnerabilities.

Doing your daily computing as an administrative user is dangerous, but running without admin can also be problematic, since many poorly written Windows applications assume the user has administrator rights. Using browsers, e-mail clients and instant messaging applications as admin is just asking for trouble.

Michael Howard from Microsoft saught to find a middle ground where one could stay logged in as admin but run certain applications in a non-admin context. The result is DropMyRights. Michael describes DropMyRights:

DropMyRights is a very simple application to help users who must run as an administrator run applications in a much-safer context—that of a non-administrator. It does this by taking the current user’s token, removing various privileges and SIDs from the token, and then using that token to start another process, such as Internet Explorer or Outlook. This tool works just as well with Mozilla’s Firefox, Eudora, or Lotus Notes e-mail.

If you’re still using a version of Windows prior to Vista, DropMyRights is a worthwhile tool for your desktop security.

And for those running Linux, none of this need apply. You’re already running as a non-privileged user.

One of the big problems in information security is how to effectively teach small businesses safe data handling. They’re too small to have dedicated security budgets and they can’t be expected to publish volumes of security policies; yet, they have needs to handle information safely above and beyond what a normal consumer has to deal with.

NIST attempts to fill this gap with the Small Business Information Security: The Fundamentals guide. In the guide they detail what a small business should minimally be concerned with, along with some extra measures they may want to take.

While it has a little ways to go (it is a draft, after all), it’s a great start to filling this much needed void. Check it out and see if they manage to walk the fine line by making security simple, yet effective enough for small business.

The Age reports that computer criminals from an underground hacker forum broke into Australian Federal Police computer systems after the police infiltrated their group. And, according to The Age, it was all because the cops forgot to set a MySQL database password.

We may need to pass around the clue stick to everyone here. If the compromise was real, the police should have known better than to leave a database exposed to the Internet and unprotected with a password. The alleged criminals need to understand that drawing more attention to yourself after you already know your under investigation is not the brightest thing to do.

Surely, the system could have been secured. It’s doubtful that it needed to be on the Internet in the first place. Or maybe, as some speculate in the article, it really was a honeypot designed to lure the not-so-bright (alleged) criminal into a trap. Maybe the police are a bit brighter than the bad guys give them credit for.

Let’s assume for the moment that this was an honest security blunder. It’s certainly the type of thing that happens every day. What’s the security lesson here and how could this have been prevented? In this particular case, two things come to mind:

1. MySQL could listen on localhost or use a socket, by default.
2. MySQL could require a decent password or heck, a password at all, to run. No password and the process aborts. For those that really want to live dangerously, they could pass a –stupid flag to run without a password.

Many security problems are preventable. Whether or not this was a honeypot, this can be used as a lesson for developers. Run secure by default and make the user choose to be insecure.

For some time now I have had problems with Yahoo! accepting mail from the domains I manage and marking the messages as spam. They continued to blackhole me depite having never been an open relay, having a valid PTR record, having a valid SPF record, not sending any spam or mailing list e-mail, sending to and from only a few select people and having nothing in the message body that could possibly be considered spammy. Only Yahoo! has problems with the server. Everyone else seems to think I’m an OK guy.

Several attempts to resolve the situation fell on deaf ears.  Several times I dutifully filled out the forms and provided all the details requested. I even requested to not receive a scripted response, hoping a human being worked somewhere at Yahoo!. The experience led me to conclude one of two things: either they really don’t care at all about letting you know how your mail server offends them or the place is so (in)efficient that the machines have risen and killed off all the humans, only to run Yahoo! all by themselves.

It seems that I have now appeased the Yahoo! mail gods. Yesterday, I implemeted Domain Keys using the excellent guide over at Brandon Checketts’ site.  Yahoo! now considers me worthy of sending mail to their underlings. I can only hope that I continue to please the Yahoo! gods, for they are all powerful.

I was recently troubleshooting a problem with WordPress and wanted to post the solution here for others to search on. If you’re experiencing the following symptoms:

• Clicking “Status: Draft Edit” does nothing
• Clicking “Visibility: Public Edit” moves the page down
• Clicking “Publish immediately Edit” does nothing
• You can’t add tags from the “Add New Post” screen

…the reason may be the Apache LimitRequestFieldSize directive. There are a few other similar symptoms, but they mostly boil down to, “I clicked something and nothing happened.”

Most posts I encountered said something along the lines of, “clear your cache, disable all your plugins and try again.” For some people this works, but it didn’t work for me.

I discovered that the problem was directly related to the value of the LimitRequestFieldSize directive. The default value of 8190 is probably OK for almost all situations, although there is a slight risk leaving the value that high. The CIS Apache Benchmark recommends a value of 100, which in my experience is not usable for most applications. I tried a value of 500, which didn’t make much of a difference. Inching the value up bit-by-bit eventually hit that magic number that made everything start working.

Depending on your environment and the size of the headers your browser is sending, you may need to adjust this value up or down, but try to stay on the conservative side to protect yourself from buffer overflows.

One final note, this is a server-wide directive and cannot be placed in a virtual host container.