Automatically Delete TEMP Folder in Windows (no installs required)

When I use Linux, I love that anything I place in /tmp will be wiped when I shut the system down. Windows, out of the box, doesn’t do this for your %TEMP% folder. Google this, and you’ll find many people advising to install one free tool or another. I am very wary of unnecessary installations on my Windows machines. The advice given here at WindowsForum.org requires no installations. It was meant for Windows XP Pro, but I found today that it worked just as well on my Windows 7 Professional system.

Unlike the fixed /tmp location in Linux, Windows determines the value of %TEMP% and create that folder dynamically at every login. Firefox doesn’t seem to accept %TEMP% as a valid value in browser.download.dir on about:config. Therefore, I

  1. keep a sidebar shortcut to %TEMP% in Windows Explorer, and
  2. select “Always ask me where to save files” in the Downloads section of the General tab of the Options dialog.

That way, it is easy for me to select my %TEMP% folder when downloading in Firefox, as well to access it from Windows Explorer.

Trouble installing Flash on Windows? Check your system clock.

When Adobe released their last security updates for Flash, I was unable to install them on one of my Windows PC’s for either Firefox (plugin version) or Internet Explorer (ActiveX version). I scoured the web and Adobe forums, and approached the problem many different ways, even completely removing Flash from my system, and downloading special MSI installer files from Adobe. Always, the same problem. The installation process starts, then goes nowhere. I get a process for the installation in Task Manager taking up about 10 MB of RAM, and 0% of CPU, that never goes away, and never does anything.

I had resigned that I was never going to have Flash on FF or IE on this system again, unless I re-installed Windows. Then the other day, I randomly noticed that the system clock was 5 hours fast. I’m not sure how or when this happened. I don’t pay attention to the clock on this system because it’s a living room television-attached system mostly for entertainment. Anyways, I corrected the time, and decided to try installing Flash again. Both Plugin-based (for Firefox) and ActiveX-based (for IE) installations went perfectly.

For the curious, the version of Windows is Windows 7 Home Premium, 64-bit.

Solved Issue with VirtualBox Shared Folders and Lubuntu 13.10 Guest

Yesterday, I upgraded my Ubuntu Gnome 13.04 (64-bit) virtual machine to Lubuntu 13.10. I rely on the VirtualBox Shared Folders feature to keep my git repositories in sync with bare copies on network drives at my workplace. (My Host OS is Windows 7, and my workplace IT infrastructure is Windows-based.)

To my horror, today I discovered I could not access my shared folders from my new Guest OS. I even created a “clean” new Lubuntu 13.10 guest machine, which exhibited the same issue. (Yes, I carefully performed the dance of apt-get update, upgrade, install dkms, install guest additions, and rebooting after each install.) So I knew it wasn’t an issue with the upgrade process.

Then, I remembered that the other day, I saw an Oracle announcement that VirtualBox 4.3.0 had been released. I’m running version 4.2.18. Sure enough, upgrading to the latest VirtualBox, and installing its Guest Additions solved the issue. I’m assuming there have been changes in the Linux Kernel (Ubuntu 13.10 is running the 3.11 kernel) that necessitated updates to Guest Additions.

Security Explorations Says More Critical Java Vulnerabilities Left Unpatched in Latest Update

In a new article in the Register (http://goo.gl/8lzRr), subtitled Emergency fix rushed out half-baked, author Neil McCallister is just a little too alarmist. The only bit of new information here is that, of the 31 vulnerabilities that Security Explorations notified Oracle of in April, there are at least 2 more unpatched that the security firm considers critical. By critical, I mean code being able to bypass the Java security sandbox.

Almost buried in the article is that these vulnerabilities are not zero-day vulnerabilities, i.e., there are no known exploits in the wild yet. I don’t think Oracle is under any obligation to get these patched immediately as long as the white hats have all kept the details under wraps. It would be nice if they did patch them, but who knows how many other critical vulnerabilities they are working on fixes for?

In fairness, this situation is the counter-argument to my conclusion in my previous blog post that quarterly scheduled updates are probably fine. Knowing that these vulnerabilities exists makes me wish that there was a monthly update, hopefully including the fix for these, coming up in September, rather than a quarterly one in October.

Oracle Quickly Patches Latest Zero-Day. Would a Monthly Update Schedule Have Helped?

Less than a week after the announcement of a new zero-day vulnerability affecting Java 7 (see http://goo.gl/QZrxlp and http://goo.gl/nZZkE), Oracle has released a fix in the form of Java 7 Update 7: http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html

Perhaps this is not too surprising, given that Polish security firm Security Expectations claims to have notified Oracle of the vulnerability (which is actually 2 vulnerabilities combined) earlier this year in April (see http://goo.gl/oVZCK). Now the details of who knew what, and when, are very interesting, but that is not what I wish to write about here.

I want to consider if this would have played out much different if Oracle had changed their stance that a quarterly update schedule is sufficient, to adopting a more Microsoftian monthly update schedule. Here are the approximate relevant dates:

  • 2012-Apr-02: Security Expectations reports vulnerabilities to Oracle.
  • 2012-Apr-17: Scheduled Oracle Update (Java 7 Update 5). See http://goo.gl/KzQHb for schedule details.
  • 2012-Jul-17: Most recent scheduled Oracle Update (Java 7 Update 6).
  • 2012-Aug-26: Reports emerge of exploits found in the wild of the latest zero day vulnerability CVE-2012-4681.
  • 2012-Aug-30: Out of band security patch (Java 7 Update 7).
  • 2012-Oct-16: Next scheduled Oracle Update

So, not one, but two scheduled updates went by without these particular vulnerabilities patched. However, by their own accounting, Oracle patched 175 vulnerabilities in these two releases. In such a widely exposed product as Java, which represents a very large number of lines of code, vulnerability reports must come in almost every day.

In fact, Oracle’s number gives about 1 vulnerability being fixed per day. In addition, Oracle, like Microsoft, is under pressure from the marketplace to keep innovating and adding features to their flagship products. Any experienced developer will tell  you that new code inevitably brings new bugs, including security vulnerabilities.

Suppose Oracle were releasing monthly patches, and had the opportunity to push out another 30 or so fixes by, say, August 14 (the Tuesday closest to the 17th). Without knowing there were exploits brewing in the wild for this particular pair of vulnerabilities, they have to prioritize based on where they think the software is most vulnerable. There is a non-zero likelihood of being wrong in that assessment.

So, while I have been in agreement with much of the community that a monthly patch cycle would be an improvement for customer security, I can’t argue strongly that it would have helped in this case.

How to Fix Firefox and Chrome Default of Retaining Session Cookies Insecurely

On last week’s episode of the Security Now podcast (Listener Feedback #147, transcript at http://www.grc.com/sn/sn-360.htm), listener Anthony in Melbourne, Australia informed Steve Gibson and the world of a surprising fact. Of the three major browsers, only Internet Explorer respects session cookies properly. By respects, I mean that any web site session cookie should only reside in transient memory and not be persisted to your hard drive.

It appears that for a while now, both Firefox and Chrome have, for the convenience of their users, restored session cookies between browser shut down and restart. This is convenient, but insecure. Only persistent cookies should restore in this way. A common example of the usage of persistent cookies is when you check “keep me logged in” or “remember me” when logging into a site.

Neither Mozilla nor Google seem inclined to revert to the correct secure behavior that IE has kept. If you really love using their browsers (like me), but want to fix this, I’ve given the steps below.

Firefox

As discussed on the podcast, the way to get the correct secure behavior back in Firefox is to browse to about:config, enter ‘sessionstore’ in the search box, and change browser.sessionstore.privacy_level from 0 to 2.

SNAGHTMLf523d9

Chrome

I had to dig around for this one. It seems from the discussion at http://goo.gl/YyHiL that the session cookie-restoring behavior is only in the case where “Continue where I left off” is selected in Chrome’s settings. Note in the picture below, I did not have this set:

SNAGHTMLf96971

Make sure “Continue where I left off” is not selected in your browser either. In addition (from http://code.google.com/p/chromium/issues/detail?id=130291#c27): Browse to chrome://flags, Press CTRL-F and enter ‘disable better’ to jump to the “Disable Better session restore” flag. Enable it.

SNAGHTMLfbe8fc