Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

Drama Already at BlackHat!

July 31, 2007

Smart card redirection is *not* a new feature

July 25, 2007

RDC COM Registration Error

Follow-up to my Software Licensing post

July 23, 2007

I received a response to my recent post about software licensing (http://jwsecure.com/dan/2007/07/software_licensing_is_such_a_c.html) from Alan Shimel, inviting me to review his responses on his blog. This post of his - http://www.stillsecureafteralltheseyears.com/ashimmy/2007/07/snort-gpl-open-.html - seems to be the most direct rebuttal to the links I referenced.

I guess Alan’s note was also a nice little lesson in guerrilla PR … anyway, see you at BlackHat!

Software Licensing is Such a Cluster Fcuk

July 19, 2007

Although I’ve admittedly been away from the OSS game for a while (remember Slackware 1.1?), the advent of GPLv3 and the ruckus it’s visiting on some unwitting community-based software companies is irresistible. To wit, check out the following back-and-forth between Martin Roesch, founder of the open source Intrusion Detection X Snort, and various other contributors and licensees, including Alan Shimel of StillSecure.

http://sourceforge.net/mailarchive/forum.php?thread_name=7451F17A-763F-47A4-8AEC-7D91E8276C23%40sourcefire.com&forum_name=snort-users

After skimming that, read this, both because it’s witty and also because it’s a nice summary of the issues at play:

http://www.matasano.com/log/858/alan-shimel-should-stop-talking-about-snorts-licensing/.

I have to admit that I have had contempt for GPL, because it’s always said to me, of its contributors, "I can’t figure out how to make licensing profit from this software, but I don’t want to feel as though I’ve wasted my time, therefore I’ll make it public but try to prevent other potentially more clever people from profiting." Of course, people, clever or otherwise, are constantly seeking new and old ways to make money.

But, as observed in the Matasano post above - and this is something that I had not fully grasped until now - GPL has been an opportunity to build an intellectual property based business around community-developed software.

Okay - now for part two of this post - lest you think that non-community based software is being spared the licensing drama: eminent software business researcher and MIT professor Michael Cusumano has an article entitled "The Changing Labyrinth of Software Pricing" in the July 2007 Communications of the ACM (amazingly, there appears to be a link here - http://delivery.acm.org/10.1145/1280000/1272531/p19-cusumano.pdf?key1=1272531&key2=2761884811&coll=GUIDE&dl=&CFID=15151515&CFTOKEN=6184618).

Before reading the CACM article, I was under the impression that the software-as-a-service (SAS) licensing model - wherein applications are hosted, pricing is month-to-month, and if you stop paying then you no longer have access to the app - was slowly overcoming the perpetual license model (a la Microsoft Word; you pay for it once and you get to keep it). But no - Cusumano cites a recent study showing that "subscription pricing was actually declining, though vendors expected it to rise in the next several years."

Why is (was) subscription pricing declining? I don’t know; that finding is pretty surprising (although I haven’t read the study). Maybe IT purchasing managers just don’t understand it yet. Or, more likely, ISVs haven’t found the right formula.

The SAS model is actually attractive to me as a consumer. That said, I must admit that all of the software I currently use is based on the familiar one-time license fee pricing model. Would I go to a subscription model for Office (as long as I felt it was priced fairly)? Yes. Would I do so for development tools? Maybe not: one tends to want to have more control over upgrades to that type of tool, for compatibility reasons.

Boeing Gets Racked by Seattle PI

July 18, 2007

The Seattle PI ran a juicy front page headline yesterday - "Computer security faults put Boeing at risk". The article is here - http://seattlepi.nwsource.com/business/323923_boeing17.html.

Read the headline, skim the article, then read the headline again. The article actually has little to do with computer security. Instead, it’s about internal company politics, the alleged deficiencies of Boeing’s primary external auditor, and the (hello, old news) drama of SOX compliance.

The Laffer Curve

July 15, 2007

I had the opportunity, while reading the Friday (7/13/2007) Wall Street Journal editorial section, to learn for the first time about a fascinating taxation argument known as the Laffer Curve. It’s not a new concept, but I wasn’t a business owner during the Reagan days of supply-side economics, so it probably would have escaped my attention anyway.

(This link appears to provide free access - http://online.wsj.com/article/SB118428874152665452.html?mod=opinion&ojcontent=otep. This link - http://en.wikipedia.org/wiki/Laffer_curve - also makes for interesting reading since, whereas the Journal piece is decidedly pro-, the wikipedia one is somewhat balanced to con-.)

Anyway, the premise is that there’s an optimum rate of taxation, above and below which the government’s income drops off. Below the optimum, there’s money being left on the table. Above the optimum, companies (for example) are incentivised (gotta love that word) to find more loopholes, to move their operations to more favorable business climates overseas, etc, in order to mitigate an overly-burdensome domestic tax rate.

The example cited is Ireland, which taxes its corporations at a quite low 12.5%, but collects 3.6% of its GDP from corp tax sources. Compare to the US, which has a corp tax of 34.4% and collects only 2.5% of its GDP from that base.

The Safe Exception Handler Table

July 6, 2007

Okay - next experiment was to try to figure out how to tell the difference between binaries built with and without the /SAFESEH Visual C++ linker option. Here’s a pretty good explanation of what that linker option does - http://msdn2.microsoft.com/en-us/library/9a89h429(VS.80).aspx, but it doesn’t explain why it should be used, or what happens if something goes wrong in a SafeSEH image at runtime.Then I realized that SafeSEH is really just another name for software-enforced data execution prevention, or DEP. See this link - http://technet.microsoft.com/en-us/library/bb457155.aspx.

If software-enforced DEP is enabled, and the image is compiled SafeSEH, a run-time exception will only be dispatched if the exception handler is registered in the image header. It’s not stated explicitly what happens if an otherwise matching but un-registered (and therefore presumably compromised) handler is encountered on the stack. I guess either a handler in the registered chain is used instead, or a STATUS_ACCESS_VIOLATION exception is raised. Either way, the process is most likely toast, which is the desired defensive outcome.

I suppose the registered handler table could be brute-force overriden by locating its virtual address, marking it as writable, and then clobbering the first address in the chain with a new one. Mounting such an attack would seem to require the ability to run arbitrary code, in which case all is lost anyway. However, it’s clear that SafeSEH and hardware-enforced DEP complement each other quite well with respect to reducing the damage that is likely to be done following a stack buffer overflow.

Anyway, returning to the original question, detecting the presence of the safe exception handler table turns out to be pretty easy with dumpbin. The following sections - Load Config and Safe Exception Handler Table - are completely missing from binaries built without SafeSEH.

>link /dump /all On\xxx.dll

…

Section contains the following load config:

…

1001405C Security Cookie

10012F40 Safe Exception Handler Table

B Safe Exception Handler Count

Safe Exception Handler Table

Address

——–

10002BE0 __except_handler4

…

Interestingly, even when compiling code that doesn’t explicitly use SEH (http://msdn2.microsoft.com/en-us/library/ms680657.aspx) or C++ exceptions, linking against any of the usual default run time libraries (at least in Visual C++ 2005) seems to result in the presence of the above PE header tables. Indeed, according to the docs, safe SEH info will be present by default unless the image is linked against a library built with an older version of the compiler. Explicit usage of the /SAFESEH option in that situation results in a link-time error, which makes it a good reminder to recompile.

Finding the /NXCOMPAT bit

I’ve recently been reading about the Visual C++ /NXCOMPAT linker option, which indicates to the loader that the image in question is compatible with the no-execute feature supported by most processors these days, and exposed by the operating system.

http://msdn2.microsoft.com/en-us/library/ms235442(VS.80).aspx

http://developer.amd.com/articlex.jsp?id=143

http://en.wikipedia.org/wiki/NX_bit

In summary, NX is an important security feature which allows memory pages to be marked as non-executable, and for that protection to be enforced via hardware. That way, for example, if a compromised process attempts to execute instructions written to the stack following a buffer overflow, an exception will be raised instead.

There are still two issues to be aware of, though. First, the exception handler may have been compromised. In that case, following the raise, control will be returned to hacker code anyway. The second issue is that a memory page can be marked executable programmatically, although that would generally be a much tougher attack to mount remotely.

The first thing I was wondering is how to tell if a PE binary has the NXCOMPAT bit set. I found the answer in the 3rd post of this thread - http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=163194&SiteID=1. To confirm, I built a simple x86 test program, first without the /NXCOMPT linker option, and did a dumpbin. Highlights:

>link.exe /dump /headers NxOn\Test.exe

…

OPTIONAL HEADER VALUES

…

0 DLL characteristics

Next, I built the program with the /NXCOMPAT linker option and did a dumpbin:

>link.exe /dump /headers NxOn\Test.exe

…

OPTIONAL HEADER VALUES

…

100 DLL characteristics

NX compatible

To fully satisfy my curiousity, I next tried the same thing on two x64 builds of the same test code. Got the same result; the 0×100 bit is set in the DLL characteristics field of the PE optional header values only if linked with /NXCOMPAT. Interestingly, in both x64 binaries, and unlike the x86 ones, the 0×8000 bit ("Terminal Server Aware"; http://msdn2.microsoft.com/en-us/library/01cfys9z(VS.80).aspx) is also set.

Search:

Archives

Recent Posts

• Cloud developers
• Microsoft Security Intelligence Report v8
• Windows LNK bug and SCADA vuln
• Mobile devices + Cloud
• Concurrency, Security, and Windows

RSS Feed

Blogroll

Security Focus: