First just a fun little post on Slashdot which debates what /etc stands for

Now for the security related stuff:

The Month of PHP Bugs continues with two new vulnerabilities. Fortunately these bugs were disclosed to the PHP team beforehand, so updating to the latest version solves them. Also, one of them is in the WDDX extension, which seems to be in a particularly poor shape, and you might consider disabling it (because in my 7+ years of PHP programming I’ve never seen code using it and had to look up myself what it stands for). Of course we all know that all non-used extensions should be disabled, but my advice was given from the point of a shared hosting provider whos goals include providing her clients with as much functionality as possible. Then again these (and most probably the coming) vulnerabilities show that once you run someone elses code (be it in whatever high language you may think is sufficiently sandboxed), you take on risks (and big risks with PHP).

Joanna Rutkowska held her presentation at BlackHat (slides available) about bypassing hardware-based memory readers. The gist of it is that (a) you can map certain memory ranges to go to I/O ports rather than the memory (the so called Memory Mapped I/O) and (b) the DMA controller goes through an extra chip while reading compared to the CPU. The attack is to reprogram that extra chip, resulting in showing different results to the data acquisition card than to the CPU (effectively hiding any code the author wishes). My opinion: this is certainly interesting, but can easily fixed by the vendors of the memory imaging cards. Then again, to perform such manipulations, the code must be in ring-0 (or kernel mode) and then it becomes an arms race (for example you can use the CPU debug registers – with some restrictions – to watch the I/O as show by this recently published article on rootkit.com). Again, rootkits and anti-rootkits are irrelevant, and people (programmers, system administrators, policy makers) should try to implement the policy of least privilege where possible.

And finally, there is a post over at Arbor Networks which talks about how every type of file (including RTF, PDF, DOC, etc) can be dangerous. It seems that the days of reject executable attachments are gone. What can we tell our users? In my opinion we should stick to the old message (do not open executable attachments) for two reasons: to be consistent and because this filters out a large portion of the nasties out there. As for these other issues: patch, patch, patch.