The gist of it: there are some flaws in the ActiveX controls VMWare installs. The possible attack scenario for these vulnerabilities looks like this:

1. The user has VMWare (or VMWare Disk Mounter for the first two vulnerabilities!_ installed
2. The user use Internet Explorer in the host machine to visit a malicious website
3. The user’s computer gets exploited

These vulnerabilities have nothing to do with a program being able to escape from the guest to the host (as many articles suggested).

Also, if you are going to link to a paper discussing serious flaws of virtualization products, at least link to Peter Ferrie’s whitepaper or the Google whitepaper (warning, PDF!). I do not wish to belittle the research done by Ed Skoudis, I consider the ideas presented in their paper too high level and only of limited effectiveness. It is only the first step in the VM-detection – VM-detection-detection race and only effective because the attackers didn’t need to come up with more sophisticated ways.

In conclusion: VM are still the safest way to study malware, however (as with everything) one needs to use a layered security approach (so at least VM’s on a separate, non-public network). Also, there is the possibility to use private-builds of the open source virtual machines (yes, open source is great!) by security researchers, effectively turning the advantage of the malware authors (the fact that defensive software is publicly available and they can study it and modify their code until it’s not detected by the current version) against them (in the sense that at this moment the malware is publicly available and the researcher can tweak her VM until it’s not detected).

Update: now here is a vulnerability with real concerns: VMware Workstation Shared Folders Directory Traversal Vulnerability (via the Pauldotcom blog). However the solution is still relatively simple: disable shared folders (you should disable all convenience features – like shared folders, networking or VMWare Tools – when working with malware to minimize the attack surface!)

Update 2: see the posting on Security Ripcord which contains a response from Ed Skoudis in the comments that reveals some additional information.

• Update to PHP 5.2.1 and watch out for the next version and update to it as soon as it comes out. Do not PHP4, because there is a vulnerability which will not be fixed by the developers (because PHP4 is considered old code).
• Install Suhosin (unfortunately it is currently only available for Linux)
• If you have the Zend platform installed, take on look here to see if you are vulnerable to these exploits
• Disable the following functions (there are some very common functions here, so unless you run your own server, you won’t be able to generally disable them):
  • phpinfo()
  • substr_compare() – if you really need this function, you can find a replacement for it written in PHP on the documentation page (I didn’t test it, but it looks like it should work).
  • mb_parse_str()
  • iptcembed() – already disabled if you disabled the GD extension
• Disable the following extensions (they are rarely used, so in case you are a shared hosting, most probably you can get away with disabling them – of course if you host your own servers you should disable all the extensions which you don’t use!):
  • WDDX
  • Ovrimos (in PECL, but you may have installed it with an older version of PHP)
  • The zip extension from PECL
  • bz2_filter
  • SQLite – the issues with it are fixed in PHP 5.2.1, however be sure to read the description here before relaxing (because you might use a different version than you think).
  • the GD extension – this is relatively widely used, so you can get away with disabling it only if you own you own server

Also my previous recomendations remain valid:

• Run PHP as CGI rather than shared module
• Configure your firewall rules strictly (if you don’t have anything on port 4444, do not open port 4444!)
• Consider using mod_security. While it is not perfect, it provides you with an added layer of security
• If you are using a shared host account, consider moving to dedicated servers of VPS’s! If you decided against it, consider it again! Think about this

Of course even you apply all these measures you won’t be 100% safe, because some bugs remain unfixed and Esser hinted that he might be back later this month with an other month worth of PHP bugs.

• Two bugs using which you can bypass the open_basedir restriction. They are in the user-contributed PECL modules, so there is a chance that they will be fixed before a PHP update. The bad news is that this agains shows that running on a shared server provides minimal security and you really should go with your own server.
• Some local code execution vulnerabilities! What this means is that anyone capable running PHP code on the same system (virtual or otherwise) can escape the PHP sandbox and directly run binary code! This means that any built-in PHP protection (like disable_functions or open_basedir) become useless! Also, remember that if your scripts (or other users scripts running under the same account – in case of a shared hosting) contain a remote include vulnerability, the attacker doesn’t even have to have an account to run arbitrary PHP code!
• A vulnerability to activate register_globals, even if it has been deactivated from the php.ini (or .htaccess). As it stated in the advisory:
  

  The danger of this vulnerability is that nowadays many scripts try to protect themself against register_globals being activated by warning the user that it is activated, by refusing to work while it is activated or by trying to undo it, when it is activated.

  However when this vulnerability is exploited the script is unable to realise that register_globals is activated (without dirty tricks) and therefore believes it runs with register_globals deactivated.

  The solution (when you code PHP) is to properly initialize variables before using them (and not relying on them havin the 0 / empty string / null value).

• An error in the unserialize code. This can be triggered remotely if the script uses serialized data to pass state information between script invocations. Fortunately this is only an information disclosure vulnerability.

The conclusion seems to be that PHP is completely inadequate to run any external-facing web-services (which is a real shame given all the useful applications developed in it). As a mitigating measure one should move away from shared servers and implement multiple layers of security, like:

• An application firewall like mod_security
• A firewall on each host, with proper rules like (a) not allowing the host running the webserver to be contacted on any other port than 80 or 443 (many shellcodes open ports and listen there for connections) (b) not allowing the host to make outbout connections (this protects against reverse shells and bots which use IRC for command and control) and (c) only allowing connexions to back-end hosts (like a database server) from known sources (like your webserver).
• Use different (and long) passwords for different accounts so that one compromised password doesn’t result in further compromise.

• 1 mod_security bypass – present in the latest release version (2.1.0)
• 1 bug in the PHP4 Ovrimos extension – disable the extension since it seems to be particularly bug ridden (also, remember to enable the minimum set of extensions which is necessary for your code to function)
• 1 arbitrary code execution in the PECL ZIP – disable this extension now! Given that this is not part of PHP Core, we might see an update sooner. On the flip side, arbitrary code execution is bad, because if you (as most of the people) load PHP as an Apache module (for performance reasons), the current PHP interpreter equals the current Apache process, which can contain sensitive information (like SSL certificates!)
• 2 memory read exploits – the first one (not patched in 5.2.1) allows a limited range memory read, but still enough to read some special values (like stack canaries). The second one (which is luckily addressed by the latest release – one more reason to upgrade!) allows arbitrary memory read in the current process (which is Apache if PHP is loaded as a dynamic library).
• The PHP filtering extension also had it share of problems with 2 bugs, which could result in not 100% sanitization of the input, luckily both are fixed in the latest release.

My opinion / advice: in the light of these vulnerabilities (and other, much older issues), shared servers with PHP are almost inherently impossible to secure. Go with a separate server or at lease a Private Virtual Server if possible at all. Apply layered security. One of the advisories said:

This bug shows one of the weaknesses behind the ext/filter idea. Whenever there is a bug in the filter implementation all applications that make use of it are vulnerable and can only be fixed by upgrading the PHP version (because the filter extension is static by default).

This is true, however you shouldn’t draw the conclusion that these solutions are useless (or that mod_security is useless, just because a bug was found). Such reasoning misses the point. Lets say that normally your system is vulnerable to X exploits. After you install some security add-on (like mod_security of Suhosin), your system is vulnerable to Y exploits. As longs as Y is less than X (and most of the time it is considerably less), it is worth considering the deployment of that product (and I emphasize considering, because you must think about many other issues before deploying such products, like how many applications / scripts will it break and how much time does it require for fine-tuning). And just because Y is not 0, doesn’t mean that you should avoid using the product and stay vulnerable to a much larger set of problems.

Finally, you should consider going the FastCGI route to separate the script interpreter from the web server (in fact you should go the plain CGI route, but this may yield performance which is unacceptable).

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.

My advice remains the same: forget shared hosting (both as a client and as a Service Provider) and patch, patch, patch – also consider things like Suhosin and mod_security. I know that (especially the later) can be a pain in the rear end to configure, but the alternative – being owned or DoS-ed out of existence – is by no means better.

PS. This week seems to be a bad one for PHP security since the distribution server for WordPress (a popular blogging platform written in PHP) was compromised – my respect to them for saying cracker, not hacker – and contains a backdoor. Via Slashdot.

The situation currently is: if you are running on a dedicated (virtual) server, you don’t have anything new to worry about (since supposedly your programmers don’t intentionally try to crash your webserver). On the other hand if you are running (or using) shared hosting, be worried, very worried. One malicious user or one easily hackable PHP script can make your server an easy target for DoS attacks with these bugs.

It seems rather curious that the PHP developers were against the fixing of these flaws (if you can believe Stefan Esser, after all you have to take the word if all involved parties with a grain of salt), because it is something that Perl is doing, most probably for many years.

If all the bugs stay in this area, people running / using dedicated hosting will be relatively safe (as safe as were until now). The clients of shared hosting companies should try to migrate anything remotely important or confidential over to dedicated hosting if the given shared hosting company provides PHP (and most of them do, except for the ASP ones) or at least convince them to install Suhosin (which they probably won’t). Don’t even try to convince them to use mod_security, because while Suhosin shouldn’t require many configuration and most probably won’t break anything for anybody, this certainly will.

I completely disagree with the decision for security companies, researchers and individuals to make information on vulnerabilties, or how to exploit them, public without following responsible disclosure – this is not very responsible Organizations should NOT do business with entities that put our networks at risk – period!

Needless to say I disagree with him completely, one of the reasons being that is business suit type of person (a former Gartner analyst). That said, over on the securosis.com blog you can read a very detailed and very balanced description of the disclosure process and the problems with it.

If you still prefer to read this blog posts, here are the key points you should keep in mind when discussing vulnerabilities:

• The bugs are not created by the researchers. The bugs are created by the company (or rather the programmers of the company) so morally speaking they are responsible for it (unfortunately with most modern EULAs they have no legal responsibility)
• The fact that a bug is not widely known doesn’t mean that it’s not known at all. It is very possible that a limited set of people have knowledge of it and are using it for nefarious purposes.
• Given this fact, any disclosure whether its coordinated with the vendor or not, is a good thing / public service. Even more so when you consider that these very, very smart people do the work for free which the given company failed to do, even with the (hopefully) massive amount of money put in the QA department.
• One blog post pondered the fact that many people are in the fame business when publishing vulnerabilities, however you have keep in mind that: (a) as one commenter noted: even if they only supply a reliable way to reproduce the bug, this is enough for the programmers to fix it and (b) either there is a sudden increase in smart people (or at least who know how an XSS vulnerability works) or the quality of the programs if very, very low. Either way, remember: they are doing the QA departments job for free! (This is not to say that you should fire your QA department, but at least thing about bringing some of these people on your team)
• Finally, I have to wonder: would the verdict of the poster have been so harsh if the subject of the talk were business people (as opposed to technological people)?

In conclusion: this is a technological problem first and a PR problem second and should be treated by the companies that way. (Or better said: it is an economic problem first, so treat it like such: offer rewards for vulnerabilities and fix them as fast as possible – think of it as the cost you pay for not following strict security guidelines and rigorous QA testing)

Getting back to the topic here: I don’t have an opinion, since there is no such thing as a cookie virus. By definition the a virus is (quote from Wikipedia):

A computer virus is a self-replicating computer program written to alter the way a computer operates, without the permission or knowledge of the user.

There is no such thing because cookies should be (and usually are) treated by browsers as opaque tokens (that is they are not interpreted in any way and are sent back exactly as received to the server). Now one could imagine the following really far-fetched scenario which would be something similar to viruses:

A given site uses cookies to return some javascript which is evaluated at the clientside by some javascript embedded in the page (that is the code embedded in the page is looking at document.cookies and doing an eval on it. Now in this case we could make the client side javascript do whatever we want, however:

• If we can modify the client side headers, probably we have very such access to either the client or the server that there are much more malicious things that we can do.
• The javascript will be executed in the very limited context of the web page, so we could only infect other cookies that go to the same site (but we already had access to it when modifying the first cookie, so there is no reason for using such a convoluted method.

Now many sensationalist sources use the word virus to refer to all kind of malicious actions to drive up hype (and we all know what my opinion is about that). There are however some real possibilities of doing harm, most of them in the area of information theft and input validation.

• The first one (which doesn’t fit in any of the two mentioned categories) is the possibility that there is a buffer overflow exploit in the cookie handling code at the server. In the official standard it is stated that a cookie should be now larger than 4096 bytes and we all know that when something like this is in the spec many coders automatically write char buffer[4096];. However before you think that this is a 0-day against Apache or something, let me say the following: I threw together some quick code an ran it against an Apache server (2.2.something) and it very nicely refused to accept the headers. It also generated a return message which was properly escaped, so there is no possible XSS vulnerability there. I’m also sure that IIS has no such problem but maybe some home-brew custom http servers might have this problem.
• A scenario on which some papers are focusing is the following: the cookie contains some text which is relayed back to the server, which in turns embeds it in the HTML output without proper sanitization. This can result in the attacker embedding code of their choice in the page, including javascript, however such an attack has no real-life benefit, since if the attacker can access the clients cookies, s/he has probable write access to the file system and can do much more nefarious things with much less complication.
• A third possibility would be that the server relies on data contained in the cookie for authentication or for some other action. In the first case there are two vulnerabilities: cookie theft and creating a custom cookie to gain access (if the server relies for example on some value to be present in the cookie to indicate that the user authenticated successfully). The second case would be when there are parameters in the cookie for a server-side process (shopping cart information). If the server has no way of validating the information upon receiving it or doesn’t do so, one could manipulate this information to gain advantages (to buy things at a 0 price for example). Ideally this information should be kept in a server-side session storage or if you don’t want to break the REST model, encode it in the URL, but make sure that you provide a way for the server to verify the posted back information, by for example encrypting it and then appending a salted hash (where the salt is only known to the server) to it and verifying this when receiving a new request.

In conclusion: Developers – validate your input! validate your input! validate your input! (at every step)

• The first (and the more important one, although in security every item is important) was only recently publicized and involves sending an invalid header to Apache, which responds with an error page. I’ve got this one from the SecuriTeam blog. If the default error pages were not changed, they will include the invalid header, so a cross-site scripting attack is possible. To test if your site is vulnerable, you can use curl like this: curl http://localhost/asdf -H "Expect: <script>alert('Vulnerable');</script>" -v -i. If the output contains the alert, your server is vulnerable. To worsen the situation, you can use Flash or XMLHttpRequest to create these types of requests (although not with Firefox, which disallows the transmission of this header). Now don’t start filtering on Mozilla browsers, because user agents can also be spoofed. The two possible workarounds are: create custom error pages (harder if you host multiple sites) or enable mod_headers and use the following global rule: RequestHeader unset Expect early (tested with Apache 2.2.3 on WinXP). This might slow your webserver a little down as described in the documentation, but at least you’re not vulnerable until you update Apache.
• The second is a lesser problem, and involves the possibility of stealing cookies if the site has a XSS vulnerability even if the cookies are marked HttpOnly: It involves sending a TRACE request to the webserver. This request is usually used for debugging, and echoes everything back, including the cookie headers. Again Flash or XMLHttpRequest can be used to craft these special queries. A more detailed description of them can be found here: http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf. To test if your vulnerable, telnet to your webserver and enter the following commands:

  TRACE / HTTP/1.1
  Host: localhost (replace it with your host)
  X-Header: test
  
  (two enters)
  

  and you should see everything echoed back to you. As described here, you can use mod_rewrite to filter this attack, by adding the following rules:

  RewriteEngine On
  RewriteCond %{REQUEST_METHOD} ^TRACE
  RewriteRule .* - [F]
  

  And it is also a good idea to make sure that your sites are not vulnerable to XSS