The Petition Against IE6

There’s a petition that’s getting some attention in the media asking the British government to end its endorsement of Internet Explorer 6. The petition explains that IE6 is vulnerable to exploits and so encouraging users to continue using IE6 makes the users more vulnerable than if they had a more modern browser.

I’m no fan of IE, especially the broken rendering engine that has plagued the browser since its creation. Although with that said, I feel IE 8, from the a CSS and rendering engine perspective, is very nearly where it should be.

And I certainly would encourage all users to upgrade to a modern browser, be it IE 8 or Firefox or Opera or Safari or any of their countless derivatives. (I am intentionally leaving Chrome out of the list because I believe there are some deep flaws with the philosophy of its creators that doom the browser to always be problematic, but that is for another blog post.)

However I don’t agree with this petition.

The Register article states the petition’s author is the managing director of a web publishing company that recently nixed IE 6 from its support list. I’m guessing the author’s intent may not be focused solely on the safety of UK citizens, but perhaps a bit influenced by the fact that his company can not be contracted by the UK government since their company no longer supports IE6.

Perhaps I am being cynical.

The reason I do not agree with the petition is I believe any web site should be accessible in every web browser that conforms to basic HTML standards. At the end of the day a web site should work on plain text. That’s exactly what the web was made for. The whole “Rich Internet Application” junk that has spawned since is more a product of the need to “out flash” (no pun intended) the next guy. It’s the kind of design philosophy responsible for atrocities like the BLINK and MARQUEE tags.

I’m not saying that every web site should be nothing but plain text and maybe a few 8-bit images. Far from it. I’m all for incorporating new technologies, such as Flash or Javascript, to help improve the user experience. However I strongly believe that web site functionality should not rely on such technologies. You have existing standards such as the HTTP protocol’s GET and POST methods allow a web site to be interactive. If you wish to hide these operations behind some AJAX calls so users do not experience the traditional page load (because it feels more like a “real” and “interactive” computer application) that’s fine. But support for those basic methods of submitting and receiving data from your web site should still function for those who, by choice or by limitation of software, do not support HTTP/HTML extension technologies.

So I question the intent of this petition. If your web site is simply not compatible with IE6 it is because you have decided to employ newer technologies that are not compatible. You have, by choice, made your web site less accessible.

You could argue that I am contradicting myself a bit with the various CSS-based layouts I have created that, unless CSS hacks are employed, make them completely unusuable in browsers like IE6. My response is that A) part of my goal was to show people it was possible to develop web pages that DID work with older browsers while still employing newer technologies for those browsers that support it and B) I wanted to explore the limits of CSS and such exploration requires that we break older browsers if we are to find the new limits.

And every layout I do offer up for download and say “here, use it” I include vast amounts of documentation on the hacks employed, why they were employed, and I showcase that these layouts ARE compatible with the incompatible browsers. Hopefully with the work I’ve shared with my layouts I’ve been able to show at least one person that it’s really possible to make a modern web site while still being able to support older browsers; I think it’s a very important lesson for any web developer to learn. And it’s a lesson I think the author of this petition and those that have signed it need to learn.

Question for Windows Programmers

I’ve got an application (ColdFusion 8) that was (I believe) compiled with Microsoft Visual Studio. You can configure this application to load third-party DLLs to extend its functionality. When the application calls a specific function within the DLL it passes along a reference to an object (C++) in memory and the DLL is suppose to then utilize the methods in the passed object to talk back to the main application.

I have written a DLL for this application.

If I compile it in MinGW and load it into the application, the application calls the DLL function just fine. I have confirmed this by having the function create and write to a little log file letting me know every time the function is called. However, any attempt to access the passed object’s methods results in, essentially, a crash.

If I take THE VERY SAME CODE and compile it with Visual Studio Express (which is free), the DLL is able to call methods of the passed object without any problem.

Now I get that mixing compilers can lead to problems and what’s going on here probably has something to do with stack alignment or differences between how objects are passed to functions between the compiles, but surely there’s a way to make the MinGW compiled DLL handle the passed object like Visual Studio. Perhaps some switch I need to apply when I compile the DLL?

Is anyone aware of any way to do this? Or at least a link to a proper primer explaining why it’s not possible. About all I’ve found off Google are forum posts by nubs like me being told by others to not mix compilers. At the very least I want some dirty details.

Force Yourself To Keep It Secret

You should know by now that giving out your password is a bad thing. You should also know that system administrators would never ask you for your password as well. But perhaps you encounter occasions where you still give out your password, even though you know you’re not suppose to.

Here’s an idea for you.

Make your password something obscene, disgusting, or embarrassing. The idea is to make your password something you would never want to share under any circumstance. Then the next time you’re asked for your password you’ll be motivated to not give it away.

Interacting With SSL

Sometimes I find it useful to do a quick telnet session to port 80 of my web server and throw at it a few requests to see how it responds. However, how do you do this with an SSL connection? Obviously Telnet doesn’t do SSL, so is there something else that’s quick and dirty?

Why yes, there is!

I tend to keep a copy of OpenSSL installed on whatever machine I’m working. Usually it’s for the DLLs to let wget work with SSL connections or to split and splice SSL certs. But it turns out you can also use OpenSSL as a command-line client to open SSL connections to remove servers. It’s quite simple, just drop to a command line/terminal session and use the following command:

openssl s_client -host <server> -port 443

Now work the HTTP magic like you would were you using telnet. Let’s see that in action!

>openssl s_client -host www.microsoft.com -port 443

GET / HTTP/1.0
host: www.microsoft.com

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: text/html
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
Accept-Ranges: bytes
ETag: "xxxxxxxxxxxx"
Server: Microsoft-IIS/7.5
VTag: xxxxxxxxxx
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Date: Mon, 25 Jan 2010 14:51:15 GMT
Connection: keep-alive
Content-Length: 1020

Cool stuff.

More exploits. Sun responds.

Intevydis blog has another exploit or two up today for Sun Java System Web Server.

Yesterday Sun posted an alert regarding the exploits and possible temporary solutions until a patch can be released.

Their solution is to disable WebDAV and all digest authentication.

But what if I use digest authentication? Do I really need to disable it? Possibly not. The HEAD, GET and POST methods do not seem to be affected by the overflow exploits. Therefore if I block all the other methods EXCEPT those three, I should still be able to do digest authentication. Only problem is knowing every other possible method available in Sun’s web server.

Well, maybe you don’t need to know them all. You might try this:

<If $method="(GET|POST|HEAD)"></If><Else>
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
</Else>

What this does is if the method being handled is GET, POST or HEAD then nothing happens here. But if it’s something else, it gets rejected with a “method not implemented (501)” error. I couldn’t find a logical not wildcard pattern operator in the administrator’s guide (“!=” is a numercial not and will not work on strings), which is why there’s an empty IF block. Hey, it works, and remember it’s only temporary.

So if your a SJSWS person, I hope this helps a little bit.

It makes me wonder if I should ditch SJSWS entirely.

Synergy

A cool, free tool that you may very well find amazingly useful.

It’s called Synergy and what Synergy does is allow you to share one keyboard and mouse across many computers. But it’s not just a software KVM, Synergy makes switching to and controlling other computers feel a bit like a single computer with dual screens. Let’s say I have a desktop and laptop computer. I can put my laptop next to my desktop’s monitor, configure Synergy on both machines, and then simply move my mouse off the left of my desktop’s monitor and magically the cursor appears on my laptop screen. I can now run whatever applications I want on my laptop, then simply move the mouse cursor off the right of the laptop screen and I’m back on my desktop.

This is not a remote desktop program like VNC. You do not see a mirror of the desktop on the remote system. Instead you are controlling the remote system directly. This means whatever system(s) you’re controlling with Synergy will (typically) need to be within sight.

I use Synergy in a laptop/desktop environment like the example given above. I already have two monitors plugged into my desktop. Now I have my laptop as well for a total of three screens. I can use the laptop to handle simple tasks that don’t require constant attention such as monitoring e-mail, server status, etc., while I use my desktop screens to work on my current project. I also intend to bring an old Macbook back to life and add it to my configuration. In this way I’ll be able to test page development on a Mac without having bother moving over to the tiny Macbook keyboard and oddly-sensitive touch pad. Rather, I can use the keyboard and mouse I’m already quite comfortable with.

Maybe that sounds a bit lazy, but it sounds damn cool to me. Perhaps I’ll find another laptop, maybe a netbook or two, and wind up with an array of 6 or 10 screens surrounding me in my cube, each doing… something (just looking cool I suspect).

So if you’ve got a laptop and a desktop or a couple of desktops (maybe a homebrew HTPC) I’d say give Synergy a go. It’s very cool.

One small note:

Synergy has no encryption or authentication mechanism. Don’t use this over the internet or even your home wireless network unless you take some extra precautions, such as using SSH tunneling to encrypt the connection for you.

A Third SJSWS Exploit Released This Week!

Intevydis blog has released yet another exploit for Sun Java System Web Server. This one attacks diguest authentication. “Well, I don’t use digest auth, so I’m safe, right?” Wrong! Any client can trigger digest auth handling even if the web site doesn’t require a password.

I know this, not because I am clever and well versed in SJSWS. I know this because I ran the code against a test server and successfully crashed it.

So then, you and I are vulnerable to this exploit.

However there is a workaround. One that we’ve already used to prevent the previous two exploits. It requires that you manually add a couple lines to every virtual server config file in your deployment.

That code is:

<If $method="PROPFIND" or $method="OPTIONS" or $method="PUT" or $method="DELETE" or $method="MOVE" or $method="MKDIR" or $method="RMDIR">
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
</If>

This disables all the methods you probably don’t really use. OPTIONS and PUT have already been used to exploit SJSWS. Why wait for another method to be exploited? Let’s disable them all. At least until Sun comes out with a patch.

I’d like to point out one thing. When I did crash my SJSWS test deployment, it came back up within 10-15 seconds. Sun’s watchdog process keeps tabs on your server process and, should it crash, immediately starts up another. That is really handy. Granted it’d be trivial to still execute a DoS against a vulnerable server (just send the malicious request every 30 seconds), but if someone’s just trying to muck around with your server, it won’t cause any lengthy amount of downtime.

Another SJSWS Exploit

Looks like the people behind Intevydis blog have revealed another Sun Java System Web Server exploit. This one attacks WebDAV. Not a problem for me as I have WebDAV disabled across all our web servers. However it will be a problem for people who rely on WebDAV. If I were in that position I would try to get away with disabling WebDAV until Sun releases a new patch. I don’t think disabling the OPTIONS method is possible; I believe it’s needed for WebDAV. So if you’re stuck in that situation, good luck!

Contuing My Case For Designing Without Javascript (or Flash).

Last week we learned of an exploit in IE6 that allows the attacker to take control of your computer simply by having you browse to a web page and get IE to execute a bit of Javascript. Microsoft urged people to upgraded to IE8 ASAP. Well it looks like IE8 is vulnerable as well. Here are the gritty details.

Microsoft won’t have a patch ready until next week at the earliest. So for at least a few days your computer is seriously vulnerable if you’re browsing the internet with IE.

But there are temporary solutions. One is to enable Data Execution Prevent (DEP) in Vista/Windows 7 for IE. You need to do this manually, but it might save you. Except it might not, as some French researches (see first article I link to) claim to have a workaround to make the exploit work while DEP is enabled.

The only other solution? Disable Javascript in IE.

And the threat is serious enough that people (read IT admins on behalf of those under their care) may resort to this very solution.

Which means any and ever web site that employs Javascript as a key means to access content and navigate the web site will become empty pits of nothing. The sites won’t work, the users won’t be able to access them, and business it lost on both sides of the equation.

However, had one designed their web site in such a way as to NOT rely on Javascript for presenting/serving content to the user, one would not be in the business of losing business every time a new Javascript exploit comes out.

So use Flash, you say.

Well, Adobe has scripting problems of its own. In fact Adobe is recommending people disable Javascript in Acrobat Reader, just like Microsoft.

Certainly seems like we’re staring at a future where Javascript can not, and should not be relied upon to deliver your web site content.

But if you take me for a cynic, that’s okay, I’ve got some cool news for you. A programmer is implementing Flash using Javascript and SVG. This could mean your future web pages could create their own animations without the need of any third-party plugin like Flash. This is kinda cool!

Sun Java System Web Server Exploits

For the past couple weeks and at least a couple more, Intevydis blog is releasing a new, 0-day exploit every day. Today’s exploit is of particular concern for myself as it has to do with Sun Java System Web Server and I administer several servers that use SJSWS.

TRACE is used as a debugging command. The idea is you send an HTTP request using the TRACE method and the web server repeats back your entire request. Best practice is to disable this feature entirely on any production or internet-facing web server. The reason being that an attacker could potentially use TRACE to steal cookie and password information.

How?

Let’s say you log into Facebook. Someone gets your browser to run some Javascript from within the Facebook domain and send a TRACE request to the Facebook web site. The server would return the cookie information used to identify your session. An attacker could then replicate that cookie on their own computer and now have access to your Facebook account.

So if you’ve been paying attention to your web server’s security you’re probably already safe against this exploit, but if not you need to learn how to disable TRACE for your web server. That link is for SJSWS folks like myself, but there are instructions on the internet for many other servers like Apache. So hit up your nearest search engine and get your server protected.