security

Drupal 4.6.3 / 4.5.5 Fixes Critical Security Issue [Update]

Everyone using Drupal should upgrade ASAP to the new Drupal 4.6.3 (or 4.5.5 if you're running 4.5.x), as a serious security vulnerability has been found in the third-party XML-RPC library Drupal ships with. I sent the security advisory to Full-Disclosure, Bugtraq and the phpsec mailing lists, so hopefully everyone will notice and upgrade.

Note: This is not the same issue as the one which was fixed earlier!

Update: Heise has more information about the issue, now.

Drupal security.module

I released a first version of my Drupal security.module yesterday. The module is sort of an intrusion detection system for Drupal sites. It helps the site admin to check and ensure the security of his Drupal installation. Read my original announcement for more details.

The code is in ALPHA stage, so don't expect everything to work, yet.

I Adopted bfbtester

As of today, I have adopted the bfbtester Debian package (a tool to perform quick, proactive, security checks of binary programs). I have already blogged about bfbtester in the past, and used it recently to find a security-related bug in a setuid package (which is hard to exploit, though).

I have uploaded an updated bfbtester package to unstable a few minutes ago. It should reach your favorite mirror, soon.

Exploited Exploits

Someone on the security mailinglist Full-Disclosure has posted an interesting warning regarding proof-of-concept exploit code. It seems that multiple published exploits have been replaced with more malicious versions by unknown attackers.

The attackers replaced the shellcode in the demo exploits (which usually opens a root-shell) with more malicious versions like 'rm -rf /*'. As such shellcode usually consists of hex-encoded assembler instructions, most people don't have the slightest chance to understand it, and hence cannot verify what it really does. People who want to "just try out whether I'm vulnerable", might end up with a wiped hard drive (or worse).

The lesson (one of them, that is) we should learn here is to never execute any code we don't trust and/or fully understand.

(via Heise)

Security Risks of Street Photography [Update]

We live in really, really sad times. People are being increasingly harassed for taking photos of public buildings, bridges etc. (at least in the US).

There's quite a bunch of interesting comments in Bruce Schneier's blog. Basically, everyone seems to think that such measures are just plain stupid. I tend to agree.

I notice more and more misdirected efforts to "secure" our world. I'll tell you a secret: terrorists most probably won't publicly photograph any targets, they'll do it covertly, using cell phone cameras or very small miniature cameras, or whatever. Measures such as forbidding photography of public buildings simply annoy tourists, artists, or random people who like photography.

What's next? Forbid email, because terrorists could use it to communicate? Forbid planes, because terrorists could use them to destroy buildings? Forbid snail mail, because terrorists could send letter bombs? Forbid cars, because terrorists could crash them into shopping malls?

Can you spot a pattern here? You can't just forbid perfectly sound and non-malicious activities or technologies to "battle terrorism" — that's just plain stupid. You will piss off a lot of people. And it won't help anything to stop terrorists.

Update: Waaaaah! Now they try to abolish broadband Internet on planes (or at least they want to spy on you) — after all, terrorists could trigger bombs using the Internet. Yeah... I can't believe how fucking stupid some people can be.

Syndicate content