Friday, February 04, 2005 - Posts
Computer Magazine, published by the IEEE Computer Society, has a column called “32 & 16 Years Ago” (cute, eh?) in which it quotes itself in the distant past of the computer world. The current issue has this from the January 1973 issue:
James Anderson of James P. Anderson & Co. and Daniels Edwards of the National Security Agency have engaged in several studies of current operating systems with respect to security aspects and reported that several general design and implementation weaknesses existed. The weaknesses in design were probably design choices at a time when efficiency was emphasized in operating sytems rather than security. Implementation weaknesses were generally caused by time/space constraints as well as poor programming techniques.
Gosh, has nothing changed in computer security? Significantly, this is one assessment in which Microsoft comes off scott-free, since it would be two more years before it existed and a decade or so before Windows 1.0 would hit the digital bus.
Shades of Raymond Chen's Old New Thing!
There's a very nice article that went up on MSDN last month about security: Guidance on Patterns & Practices: Security by Keith Pleas. Several security-minded bloggers have written about it, so this hopefully is not news. But I'd like to share a few observations.
Keith is not a Microsoft employee, but he has been a contractor to them in various capacities for years, lately with the Patterns & Practices group that tells we who implement Microsoft technologies how to do things the best way, or at least the Microsoft way.
What I really found interesting in the article is not so much the technical information--it's a fairly high-level view--but the admission that Microsoft doesn't always release sample code that shows okay practices, much less best practices, for security. Keith talks about two specific examples, the widely discussed, used, and studied Duwamish Books and Fitch & Mather Stocks. At best, the two apps include some minor security comments in the docs that indicate that in a “real” application you surely wouldn't do such an unsafe, insecure implementation. But there are a lot of real world apps out there that do just that, either because they are extensions of one of the sample apps or because the samples were used for the basis for another app.
This is generally Good News. Even though a 'Softie didn't write it, Microsoft published it. One of the promises Microsoft has made for the 2005 edition of its development tools is to improve communications about secure practices, including how it does its sample apps. This is going to make it harder to set up the samples because you'll have a few security-related hoops to jump through; gone are the days of xcopy deployment to play with code.
The article is an interesting read as Keith puts the sample apps through a mini security review. While there isn't much depth there--the article would be many times longer if there were--it's a good exercise and a good warning about using Microsoft sample code blindly without carefully examining and analyzing it. (In fairness to the samples, some were written outside Microsoft and in more innocent times. But those are lame excuses in today's security environment, particularly some of the flaws were well-known when the samples were created or last updated. The company should pull them when they are discovered to have security flaws.)
Alas, appearance of this article doesn't mean that all is well with security in Microsoft-land. Keith's Patterns & Practices group just released their Enterprise Library 2005 with seven newly updated application blocks. The problem is that if you install it to the default location, under c:\Program Files, when you try to use them you get an error saying that you can't write to a file. (Thanks to Robert Hurlbut for first bringing this to my attention.) Which shows that the folks that developed EntLib aren't running with lesser privileges, and these tools didn't get a decent security review. Will Microsoft ever learn???? Or will they keep shipping software with these kinds of problems, even while preaching that the rest of the world use good security practices? Aargh!
Anyway, check out Keith's article. It's a worthwhile read.
Man, this is a hard one to write. I just love ActiveReports so I'm bummed that it has this problem. At least it is limited to licensing, not design and runtime use.
I was having a problem with getting rid of the red “ActiveReports Evaluation” banner that they put at the bottom of all reports until you license the app. I have a licensed copy and did all the stuff the docs say to do and the knowlege base articles suggest as workarounds. Nothing worked. I also posted to the Data Dynamics support forums but didn't get any suggestions that worked. So I sent a support request email:
Hi,
I am struggling with what seems to be a licensing problem with ActiveReports. My serial number is XXXXXXXXXXXX.
No matter what I do, I can't get rid of the red ActiveReports Evaluation banner on my WinForms-based reports. I've done these things:
- Created a licenses.licx file, which has this line in it (among others for other products): DataDynamics.ActiveReports.ActiveReport, ActiveReports
- Followed the instructions in HOWTO: How Can I Use Run-Time Licensing in ActiveReports for .NET? at http://www.datadynamics.com/ShowPost.aspx?PostID=46811. This may indicate the problem, since I couldn't complete the "Create Web.Config Key" step; it kept saying that the serial number was invalid.
I don't know if I had registered the product. When I just tried to on the Web site, it said "There were no search results found." I wasn't searching for anything; I was trying to register.
What do I need to do to get this resolved?
Thanks!
Don Kiely
(I failed to mention having run the LicensePro.exe app.) The initial response suggested stuff that I had already tried. So, to make a long story long, I ended up talking to Peter, a support rep. Once again, all the usual attempts to fix it didn't work, but then it occurred to me that because they write write licensing stuff to the registry there might be an issue that I don't run as an administrative user. That solved the problem.
It turns out that ActiveReports has a problem with licensing. If you run the LicensePro as non-administrator it silently fails to do the proper registry entries. As soon as I ran it as an administrator (RunAs worked), everything worked fine. Fortunately, it doesn't appear that there is any user profile-related information saved.
I followed up on the support call with an email that concluded like this:
Please! Do one of two things:
- Fail with a message that you need admin rights to run License.exe or LicensePro.exe for ActiveReports. This solves the immediate problem, but the bigger problem is that you shouldn't be writing to protected parts of the registry. That's a security problem.
- Stop writing to a protected portion of the registry. I haven't looked to see where you are writing, but it should be in HKEY_CURRENT_USER, and certainly not to HKEY_LOCAL_MACHINE.
ActiveReports is a wonderful product. Given my experience with their excellent support and what I know about the company, I'm betting this is fixed quickly. I hope. In the meantime, beware. But again, the product itself works beautifully as a least privileged user.
Update: Issam Elbaytam with Data Dynamics and all-around good guy, responded to my email, which I include here in its entirety with permission:
Don:
I just read your blog entry about this issue and I appreciate you bringing it to our attention, your blog does not seem to have comments so I couldn't respond there. I apologize for the trouble this might have caused you. I have forwarded this to our development staff to look into it and correct it with the appropriate solution.
I believe the reason we write to HKLM is for web server situations where we cannot make sure that the ASPNET user is registered because it is not a typical interactive user. In addition, because of the integration with VS.NET (which also writes entries to HKLM) we have to write some of our entries there too.
Regardless of the reason why we're accessing HKLM, we'll work on eliminating it and updating our licensing exe files. In addition, we'll publish a KB article to our web site that explains the current situation and its remedy.
Thanks again for bringing this to our attention.
issam
Moral of the story: Let vendors know when you run into these kinds of problems. The good ones will fix the problem.