ZERT is back at it again. They’ve released a patch for the latest Microsoft Internet Explorer vulnerability. Actually, it’s more of an automated script that disables the ActiveX controls that are vulnerable. Much easier than hand-editing the registry. Check it out if you use IE.
I’m impressed that they thought this was a severe enough problem to warrant an earlier release than the October 10th date they stated in the original Security Advisory. They have updated the original advisory and removed most of that content, however, so you’ll just have to take my word for it. And, funnily enough, they apparently used the cut and paste approach as the current revision points this out as the “Powerpoint Mso.dll Vulnerability” and not the Vgx.dll vulnerability. Well, noone’s perfect..
Now get out there and patch! And while you’re at it, check those anti-virus definitions and make sure those are up to date. And if you don’t already have some sort of firewall, get one!
Looks like there’s yet *another* IE vulnerability on the loose. This particular vulnerability uses a bug in VML (Vector Markup Language) to cause a buffer overflow and allow the attacker to gain access to the system. I’m a little late to the scene, but this was initially reported on September 18th. But FEAR NOT! Microsoft has happily released a security advisory in which they explain that they know about the vulnerability, and that they’ll release a patch on October 10th.
Umm.. October 10th? That’s almost a month *AFTER* the report was made public.. This happens to be a really nasty bug that can cause your computer to be completely compromised and they admit to knowing about code in the wild exploiting this bug!
The person who reported this was not being irresponsible and revealing a “potential” security issue the the hacker community. Quite the opposite, in fact, they were reporting a known in-the-wild exploit with the intention of informing the masses so they could act accordingly. For Microsoft to not release a patch quicker, or even publish some viable mitigation strategy is incredibly irresponsible. At the very least they could explain how to unregister the VGX.DLL file that is the source of the expoit. Luckily, Sunbelt has instructions on how to do this.
If you’re interested in a better solution, ZERT (Zeroday Emergency Response Team) has created a patch to fix the problem. Be aware that this is not sanctioned by Microsoft and is supplied As-Is. However, if you rely on IE and want a reasonable sense of security, this may be your only choice until the behemoth from Redmond decides to release an “official” patch.
If you’d like to read more about this vulnerability, check out these links :
SunbeltBLOG – These are the guys that first reported the problem
TaoSecurity – A report about ZERT and how they’re proving that the closed source security model is broken
eWeek – A report about the vulnerability and the patch that ZERT created
I also want to point out that I’m not necessarily anti-Microsoft. I believe they’ve helped out the computer industry in many ways. However, I dislike many of their practices, and this is definitely one of them. It’s important for any software developer to release security patches when necessary. It is of utmost importance for a closed-source developer to release security patches as fast as possible because they’re the only ones who can truly patch the hole. Open source allows anyone, with the necessary skills, to patch the hole. I’m not saying Microsoft should open-source Windows, but maybe they should work a little harder to put together patches with more speed.
Pawel Foremski is preparing to release the latest version (0.42) of his qmail-spp patch for qmail. This incredibly useful patch allows you to modify the behaviour of qmail, on the fly, through use of external scripts. These external scripts can be written in any programming language that allows STDIN and STDOUT. I have found this to be incredibly useful and it has haled tremendously when targeted by spammers and virii.
There was some initial concern about the overhead involved with calling an external program for processing, but my fears have been calmed since then. I’ve seen this patch in production on machines processing over 250,000 emails per day. That’s a LOT of email.
The patch allows you to inject special processing during specific portions of the smtpd process. These areas include
HELO/EHLO, MAIL, RCPT, DATA and (if supported) AUTH. There is also another hook available when the client connects, before any data is transferred between the client and server. These 6 areas allow for a massive amount of power. For instance, you can interrupt the process right after the HELO/EHLO and run an spf plugin. Or, you can check the from address during the RCPT portion and determine if the user is relaying, and if they’re allowed. Basically, a chkusr function. Tarpitting is fairly simple at the RCPT level as well. The initial connection point is a great time to check for blacklists. In fact, you can set different SPP config files for use depending on where the connection originates. Thus, you can add additional RBL lists depending on the source. So, you can skip RBL altogether for known local connections, and use a wider range of blocklists for external connections. All in all, the flexibility is incredible.
I highly recommend the use of this patch for any qmail installation intended for normal mail use. Obviously if you’re never going to allow mail delivery, there’s no real point, but if you need a strong, secure mail server, this is definitely a step in the right direction. In fact, I worked with Pawel to create a patch that will work with the SMTP AUTH/TLS patch that Bill Shupp put together. Bill has a nice page with a complete qmail toaster on it. His toaster was the basis for my own foray into the qmail scene, and I owe a lot to the work he’s done. I’ve built my own toaster based loosely on his, but using the qmail-spp patch, and some of my own experience. You can find my toaster by either clicking here, or on the link to the right.