Vista Security one year on - still not tools to help developers

Recently there is an article published that discusses various security features of Vista and how they are accepted.

With respect to the UAC, the author has this to say:

One reason for the condemnation is that many administrators believe that a lot of legacy applications are programmed to have free reign over the system; truth is, however, they end up not being compatible with Vista.

Windows professionals require elevated permissions to perform elevated tasks. Those tasks are more difficult when administrators are treated like common users. Hence, more criticism.

Even though User Account Control can be annoying at times, I think Microsoft had no choice -- it had to create this feature. Windows XP had such a bad reputation in regards to how easily it could be infected with malware that Microsoft made sure Vista was designed in a way that would prevent malware from taking over the system.

Well, some of the argument the author used is totally wrong.

There is no excuse for developers at the end of year 2007 not to be aware of the Windows Security Model that was first released with Windows 2000. If they are unable to learn by now and most I dare to assert aren't even aware of the security specification, the OS should simply banish them.

XP is given such a bad name because these developers are not well educated. Their ignorance influences other users to turn off the security model. I once questioned a well-known accounting software package why it required Administrative Rights to run and what privilege operations that needed such high level of demands. Of course, I was told it needs Admin rights. On deeper investigation, it turned out the software company was more interested in protecting its license than to protect the users machine and data by using a licensing protection software technique that obviously was poorly developed as that was the part that demands administrative rights.

Developers should not shoulder all the blame for the creation of this mess, Microsoft should share a major portion of the blame in several areas:
1) Microsoft attempts to make things easier for ordinary users by opting to allow user to run wild with no security - the easiest way out. Have you ever seen a Windows installer that when adding a new user defaulting to non-Administrator accounts?
2) Why isn't there any auditing of violation? or interception of invalid calls and logged them into event log. At least this can allow developers to have a chance to see any invalid or security violating calls.
3) Microsoft built the tools that most developers use to develop Windows software and why that tool does not have any debugging hooks to watch for this kind of violation or excessive demand of rights? And in the latest version still does not have any. In .Net 2, the debugger can pick up cross thread UI calls when using WinForm. It is at all possible. Just look at how Vista virtualizes some of this calls that would be invalid in XP running in limited users account. If it can virtualize those access to HKLM or protected folders, why can't it write an event log entry or picked up by debugger?

If Microsoft has attacked this problem when Windows 2000 is first released, by now there would not be a need to waste so much resources just to help out ignorant and arrogant developers who not only are not conversant with the security model but also are not using the operating system properly.

I have been doing all sorts of development in LUA (Least-Privilege User Account) for years now and have not encountered any issue. Sure I have to enlist Administrative mode to do certain task but in most other time, LUA is fine. The most annoying things are software package that fails to comply with LUA from large software development house, some are documented in this blog, that you would expect them to know better.

Why doesn't Microsoft host the 'Hall of Shame' of security violators much like the Hardware compatibility list?

Choose your random number generator carefully

Bruce Schneier has just released his overview of the recently released US Government's official standard for random number generator.

His disclosure of a trap door found in the Dual_EC_DRBG is something of a worry:

This is scary stuff indeed.

Even if no one knows the secret numbers, the fact that the backdoor is present makes Dual_EC_DRBG very fragile. If someone were to solve just one instance of the algorithm's elliptic-curve problem, he would effectively have the keys to the kingdom.

And his recommendation to selecting a random number generator:

My recommendation, if you're in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.

I wonder what is the purpose behind all these.

This can't serious, can it?

Someone asked a very simple question, how could I produce a PDF document from my Word document and this was one of the answers:

in the office, why not just print the word document and then using the printer, scan it and email the document to yourself, the default format is PDF.

I am not sure if the person is offering this in jest or what but I can tell you that this person is involved with technology at a senior position. That is scary.

What do you call a Windows Live Writer that does not write

The Internet is buzzed with the excitement that Windows Live has finally came out of the beta. So I installed the Messenger, Mail & Writer to see what's the fuss about the Writer. I have been a long time user of MSN messenger and WLM .

What a total disappointment when WLW can only be used with a keyboard.

Perhaps someone has forgotten to tell WL developers that there is a Microsoft Product called Tablet PC.

Looks like they have repeated the same mistake as in Windows Live Space where that blog site is hostile to tablet users, the very reason I deserted it for blog spot. Firefox is a far better editor for me on blog spot and need no Windows (Dead) Writer.

New report shows file-sharing does not harm music industry at least in Canada

It is good for everybody, industry or music lovers, to see this kind of studies. It can only be good for those open-minded people. A recently released report by University of London for Industry Canada studies the impact of file sharing on the music industries.

Of course, there are always people who refutes this with no publication of solid data. That's human nature. In this world, it is either put up or shut up. Comments like this:

It's not rocket science to work out that if you get your music for free, why would you go out and buy it.

I have also reported else where musician's view towards this issue and they have not found that file-sharing tracks is hurting their income as their income does not derive from CD sales. Rather, their main source of income is from concerts and live performance. This kind of music sharing can be good for their as kind of advertising.

Many predicts the introduction of eBook, electronic libraries, such as 24X7 and O'Reilly Library, and the Internet spells the death knell for physical books - why would anyone want to buy a physical book when one could read it mostly free? The same argument as presented above. It is interesting to know that sales figures released and available on Google have disappointed these doom-sayers and the contrary actually has happened.

It is an interesting finding:

In the aggregate, we are unable to discover any direct relationship between P2P filesharing and CD purchases in Canada. The analysis of the entire Canadian population does not uncover either a positive or negative relationship between the number of files downloaded from P2P networks and CDs purchased. That is, we find no direct evidence to suggest that the net effect of P2P file-sharing on CD purchasing is either positive or negative for Canada as a whole.
[...]
However, our analysis of the Canadian P2P file-sharing subpopulation suggests that there is a strong positive relationship between P2P file-sharing and CD purchasing. That is, among Canadians actually engaged in it, P2P file-sharing increases CD purchasing.
[...]
we find some indirect evidence that price influences CD purchasing, as the variable capturing the motivation to engage in P2P file-sharing because of the perception that CDs were too costly was negatively associated with CD purchases.

Delphi in-proc server registration/unregistration code has incomplete coverage

I have just discovered the DllRegisterServer() and DllUnregisterServer() code located in Delphi's ComServ.pas file for the ComServ unit lacks complete coverage of COM usage. It is not entirely a bug in a sense. It only means that it does not cater for all situations permitted by their language framework and supported by their IDE and COM.

However, if you are in that situation, you will not be shown any visible sign other than to discover the interfaces you are publishing are not registered. OleView.exe can show you the lack of result.

Description of the problem

When you create an ActiveX project in D2006, the IDE basically generates a plain old DLL and in Delphi's parlance, a library. What it does is to export the 4 required COM In-Proc server functions, DllRegisterServer(), DllUnreqisterServer(), DllCanUnloadNow and DllGetClassObject(). The implementations of these functions are found in ComServ.pas file.

Now if you then include a type library, you can begin to define interfaces in this library. This DLL, while devoid of any implementation, is of great significance to a COM-base solution as other in-proc or local servers can implement interfaces published in this registered type library. There is no common tool, definitely not from Microsoft, to register type library (tlb) and hence it is customarily to embed this interface only type library in an in-proc server that can be registered with DllRegisterServer() and unregistered with DllUnregisterServer().

When you do this, the D2006 produced interface only COM in-proc server will not register the type library and its interfaces as well performing the unregistration process.

RegSvr32, the Microsoft standard in-proc COM registration program, dutifully reports the information reported by DllRegisterServer() and DllUnregisterServer() supplied by CodeGear's code.

Where is the problem

It has been identified that this is caused by a crack in the design and implementation code in ComServ.pas. The implementation is based on a very narrow usage scenario, perhaps in quest of efficiency.

CodeGear assumes an in-proc server always has implementation code, known as coclass, that implements interfaces described in the type library. However, this scenario is not enforced in the IDE. You can describe as many interfaces as you like in the type library without one single coclass and the IDE nor compiler complaints.

In the CodeGear narrow usage scenario, the code in ComServ.pas expects the IClassFactory implementation in the coclass, found in the unit's initialization section generally in the form of the TAutoObjectFactory.Create(), responsible for loading the type library. This then has the flow-on effect of setting ComServer.FTypeLib in ComServ.pas.

Since the unit initialization sections are executed prior to any user code, by the time TComServer.UpdateRegistry() is called, TComServer.FTypeLib is not nil and the type library registration (unregistration) function will then be called.

However, in an ActiveX, whose sole existence is to publish interfaces, the above scenario is not realized and hence by the time TComServer.UpdateRegistry() called from DllRegisterServer() or DllUnregisterServer(), the TComServer.FTypeLib remains nil.

This situation is not considered as a bug in the UpdateRegistry() and dutifully returns S_OK resulting in fooling the user.

Incidentally, code review of Delphi 3's source code shows the same incompleteness and thus expecting the same malfunction.

Work arounds

The work arounds are listed from the most preferred method to the least.

Correct the code and embedded ComServ.pas in your project

The best way is to take a copy of ComServ.pas from CodeGear's source directory and include that into your project. It is worth removing the declaration of using ComServ in your uses statement in the DPK prior to adding the customised ComServ.pas. Failure to include this file will not bring in the fixed code.

You only need to fix the DllRegisterServer() and DllUnregisterServer() as follows:

function DllRegisterServer: HResult;
begin
 Result := S_OK;
 try
   ComServer.GetTypeLib;  // **** Added
   ComServer.UpdateRegistry(True);
 except
   Result := E_FAIL;
 end;
end;

function DllUnregisterServer: HResult;
begin
 Result := S_OK;
 try
   ComServer.GetTypeLib;  // **** Added
   ComServer.UpdateRegistry(False);
 except
   Result := E_FAIL;
 end;
end;

You only have to ensure that the type library is loaded prior to the calling of TComServer.UpdateRegistry() and hence simple addition as marked above is sufficient to rectify this problem. It only introduces slight inefficient if the CodeGear anticipated scenario is realized. As a word of optimisation, one could move the call of TComServer.GetTypeLib into the TComServer.UpdateRegistry(). But these functions are hardly frequently called functions, such operation is not really warranted.

Add a dummy coclass into project

The next best solution for those not wanting to tamper with CodeGear's code is to create a dummy coclass in a unit. This unit will then include the TAutoObjectFactory.Create call in the initialization to support the scenario expected by CodeGear. At this moment, I have not explore whether or not this coclass can be made as ole non-createable to prevent code from outside this DLL from creating it via COM API, such as CoCreateInstance().

The presence of this coclass can confuse users as that coclass will show up in tools like OleView and you then need to document its reason for existence.

This represents a compromise to a clean design.

Only good for development - use the Component Install facility

This is not really a solution as such but rather a desperate move to get them registered so that you can begin to develop with those interfaces.

This technique requires one to use the "Component | Install Component ... |Import a type library" facility available in the IDE to register the type library. Since this technique does not call DllRegisterServer() and hence it can register the type library.

However, in a deployment situation, installer relies on the invocation of DllRegisterServer() and hence this technique offers no solution in deployment scenario. Furthermore, if DllUnregisterServer() fails to unregister the type library and the interfaces, this technique does not have its complementary operation.

Post Delphi Studio 2006 installation experience

With the replacement of my old trusty work horse machine, I have to go through the ritual of reinstalling all the software packages that I use on daily basis.

One of them is the Delphi Studio 2006. With the new machine that is relatively clean in terms of LUA conformance it is also a good opportunity to see how well D2006 behaves in LUA. On my previous machine, it seemed fine but I might have been less stringent with the conformance.

As required, D2006 was installed in an Administrator account. This is an interesting fact to remember. It is not in an Administrator console. I actually logged into the Administrator's account to install. The installation went pretty flawlessly.

After that I logged back into my normal account, which is an LUA, things got interesting. With ProcMon and ProcExp configured to monitor BDS.EXE, I was ready to fire up Delphi Studio and here are the problems encountered:
1) During the start up, bds tried to copy "<.Net 1.1 Framework SDK Dir>\bin\lc.exe to the "C:\Program Files\Borland\BDS\4.0\bin" as lc.dll. Of course this is futile as I am only a LUA.

I am just wondering why Borland would want to change Microsoft's License Compiler into a License DLL. Doesn't Borland know that it can late bind into LC.EXE just as easily as LC.DLL by virtue of the CLR assembly probing algorithm coupled with reflection? All you need to do is to specify the type name correctly. But perhaps Borland did an early binding in their lab. Not very elegant in my mind. Is it also ethical to rename a Microsoft executable?

Anyway, realizing BDS is trying to do the impossible, I gave it a helping hand so as to go past this hurdle.

2) Next that showed up on the radar screen was that BDS trying to change the value of this registration item:
HKCR\TypeLib\{F939BACD-3FD5-437A-833F-BA3535A45966}\a.0\0\Win32\(Default)

Of cource this is another futile exercise. I am not allow to write to HKCR! But this issue did not seem to both BDS.

3) Next, with the IDE fully up, I began to test it. It could easily debug a VCL.Win32 HelloWorld application. But a different story when I tried to debug a VCL.Net application. As soon as I pressed the Run menu, it popped up an assertion failure dialog box (could Borland been shipping debug version of their C++ packages?)

Like this:

My machine, prior to installing D2006, has every version of .Net Frameworks installed, include 3.5 as well as all version of Visual Studio. .Net Framework are by design to support side-by-side installation and hence should be able to live in harmony. Pressing OK brought BDS crashing down instantly.

A search of Google brought me into contact with a report of this problem in Borland's Developers Network's Quality Central. You can find my rather less drastic and more .Net correct solution to this problem posted as a reply to the brutal solution offered on the Quality Central.

After the simple addition of a .Net Config file to rmtdbg100.exe, the IDE can then debug .Net application.

Incidentally, if you are building .Net COM component to be used in say Excel, make sure you give Excel an application config file to set the supported run time, otherwise, your component may fail to load because one that loads before you could change the CLR version to become incompatible with yours.

4) These operations did not cause any problem but were observed in the tools. BDS seemed to demand Generic Read/Generic Write whenever it was opening .Net system dcpil, such as System.Xml.Dcpil, etc. When the access was denied for obvious reasons, it then tried to open with Generic Read.

These operations look very strange and highly inefficient. It should demand the lease privilege particularly in a non-installation situation. Very strange. Not only BDS opening DCPIL files like this but BDS did this with other DLLs as well.

5) BDS had trouble executing in an Adminstrative Console. This is one that is constructed from RunAs command with an embedded /Netonly to provide network connectivity. It fired up fine by using the "Run As" from its short cut and from a cmd.

So far, the reason for this misbeviour has eluded me. Since this is the only program that fail to run in my Administrator console, it is not a big deal. One day, the penny will drop and so stay tune.