The Idle Thread

"Data Execution Prevention”,.. aka “No Execute” memory protection

geofhill — Thu, 12 Aug 2004 20:01:00 GMT

Intel will start shipping Xeon processors by September 24^th that take advantage of this and plan to add support for NX in all of its P4 CPUs in Q4.
There is now a software DEP built into SP2 which you can activate! It probably isn't as robust as the hardware DEP listed above, but it’s there. If you go My Computer – Properties – Advanced tab – Performance Settings button – Data Execution Tab you can turn on the software. Pretty cool, hey?

Initial Public reactions to SP2...

geofhill — Thu, 12 Aug 2004 18:51:00 GMT

Well, aside from a few crusty individuals out there who loathe all things MSFT, the media seems to be pretty positively inclined towards SP2.

http://zdnet.com.com/2100-1105-5306235.html
http://www.theregister.co.uk/2004/08/12/winxp_sp2_stop_moaning/

Though it seems that the Beeb is less willing to give MSFT anything but a lukewarm-halfhearted-positive message... bless'em.

http://news.bbc.co.uk/1/hi/technology/3557952.stm

Heh...

geofhill — Sat, 07 Aug 2004 21:02:00 GMT

Silly me, wanted to look up the definitive DEFINITION of "Rumination"...

heh heh..

And I quote,

"n.

The act of pondering; meditation.
The act or process of chewing cud.

Ok, so I grew up on a farm! Is that a reason to tar me with such a bovine brush?!?

It gets better...

geofhill — Sat, 07 Aug 2004 20:25:00 GMT

ActiveX components have always had the ability to really make a web surfer's life miserable, because you had an -effectively- local application running which could also run amock in your local machine.

But, in strides SP2 [can you tell I like this rollout?]...

We've now put in place a three layer defense system against our ActiveX buddy. First and foremost, they've gotta be signed. And that means verified by Verisign kind-of-signing. No more "this will download but I have no idea of the pedigree" kind of stuff.

First layer: the components have to be signed or they're not getting in "the door". You don't sign it, we drop it, by default.

Second layer: is it what is says it is? We now check the MIME headers to make sure that if you thought you're downloading "Anna_Kournikova.jpg", you're not downloading "Anna_Kournikova.jpg.ev1lH9k3r.exe". Neat, huh?

Part Three: All downloads are suspect. Tag'N'Bag baby. SP2 will confront you on downloading any content from the Internet Zone [it's called the Attachment Execution Services] and will recommend you don't download it.

There's another thing. We have re-engineered our download services to "No", thus preventing the horrible, "NOT-ANOTHER-DOWNLOAD-I'LL-JUST-HIT ENTER" reaction.

Oh, and did you realise that running any kind of webpage that is loaded locally... is suspect? No longer can I, as a black-hat hacker, try to run stuff on the local machine through IE, and expect to be fully accessible to the inner workings of my potential "zombie".

Out Out Damned Popup!

geofhill — Fri, 06 Aug 2004 22:09:00 GMT

There are several good reasons that popups have been addressed and consigned to the developer's version of termination. First and foremost, it was one of the biggest requests by users for IE.

But, there's another great reason for putting popups in our sights. Non-user initiated popups take control away from the browser user. That can cause anything from annoyed users to panicky users who do the wrong things in reaction to the unwanted popups. It gets potentially worse... either a hapless user gets shunted over to a socially engineered black-hat hacker website and provides information s/he should definitely NOT... or our hero downloads a piece of nasty malware inadvertently.

In strides SP2, and the completely reworked Internet Explorer. Now the popups are recognized, tagged and blocked by IE early on. No more full-screen popups that are impossible to remove. No more annoying popups which are offscreen. You get the picture.

But this leads me to the next part... DHTML. If you think that the popup writers are just going to give up and become good website citizens, you're living in a dream world. No, they're just going to recruft their websites so as to generate HTML on the fly, therefore generating floating blocks, or DHTML popups. While not necessarily true popups in the strictest sense, they still will have the same function as the dreaded popups. So why don't we take care of DHTML popups then?

Because doing so programmatically would be next to impossible. There are too many ways that a clever DHTML programmer could get around any interpreter blocking code put in by the IE dev team. Thus you would probably end up with a code-bloated IE engine which didn't work 100% in blocking the DHTML. At the base of this too is the fact that DHTML, while annoying, does not take control of the IE window away from the surfer.

All in all, the popup blocking functionality is a welcome addition to a solid browsing application.

I guess it's time for my first IE SP2 Code dump... Programmatically changing the Popup Blocker Exceptions list...

geofhill — Wed, 04 Aug 2004 02:16:00 GMT

Ok, this idea came through when I was wondering if I could automate the process of adding exceptions to the Popup Blocker Exceptions list. Now, I know that we can make a group policy for this, or we could open up IE and insert the items through the UI, but what if you weren't able to do this?

What you could do is create some kind of list which would be read by a parser and inserted into the proper location of the Registry. Pack this into an installer package and you would have a neat way of propogating an exception list without having the user doing anything directly. Remember that the installer would have to be run under adminstrator privileges, but I'm assuming that this little job here would be done by an administrator.

So, we start with a list. It's a pretty simple thing, really... just a couple of lines of xml.

<?xml version="1.0" encoding="utf-8" ?>

<Exception>*.popuptest.com</Exception>

<Exception>*.microsoft.com</Exception>

<Exception>*.aaronsauve.com</Exception>

</PopupExceptionList>

I then found out where in the registry the Exceptions List was stored and made a note of this. As a next to last step, I crufted up a small application that would read in the xml, and then write it out to the registry, thus creating my list:

Module InsertPopupExceptions

Sub InstallPopupExceptions()

'I have to create an empty binary key value for the registry key here

Dim binaryKey() As Byte = {}

'I load the xml list here

Dim xmlExceptionsList As New Xml.XmlTextReader_

(System.Environment.CurrentDirectory + "\PopupExceptionsList.xml")

'I now instantiate the registry key at the location where the popup exceptions go

Dim regKey As RegistryKey = Registry.CurrentUser.CreateSubKey_

("SOFTWARE\Microsoft\Internet Explorer\New Windows\Allow")

While xmlExceptionsList.Read

Try

'add values here

If xmlExceptionsList.NodeType = Xml.XmlNodeType.Text Then

regKey.SetValue(xmlExceptionsList.Value, binaryKey)

End If

Catch _exc As Exception

'I haven't actually instantiated an exception here yet.

'TODO Show("failed, Reason: " + _exc.InnerException.Message)

End Try

End While

End Sub

End Module

The last step here would be to create an installer project and proceed to override the install method with the above subroutine. Build the installer project and voila, you have your automated Exceptions List installer!