Avant Browser

For a little over a month now, I've been using "Avant Browser" - a "wrapper" of sorts around Internet Explorer. I saw it, got curious, and tried it. I suppose Firefox can do much of the same (or more, depending on extensions), but I just like the way Avant Browser does things. One thing I really find useful is the "Groups" function - take a bunch of websites, throw them in a Group, and then you can open one or all of the sites in the group. It's a bit like "Favorites, evolved". I used to set up batch files that would spawn 20-30 web pages each in its own instance of iexplore.exe. That was slow and tedious to maintain. Avant Browser makes it easy. There are plenty of other features as well, but I'm sure it's been covered in depth elsewhere. It works, and that's all there is to it.

Rootkits in 2005

James Butler and Sherri Sparks have some articles on SecurityFocus.com about Windows Rootkits...

Windows rootkits in 2005, part one
http://www.securityfocus.com/infocus/1850

Windows rootkits in 2005, part two
http://www.securityfocus.com/infocus/1851

Wrong file, ASP.NET. Thanks anyways.

The other day, on a test server, ASP.NET was giving the following message:

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.

Compiler Error Message: CS0016: Could not write to output file 'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\somepath\10d62725\cb6c7d34\k_kdx1bc.dll' -- 'Access is denied. '

Of course, it wasn't quite that simple. There was no problem accessing that folder, as FILEMON from Sysinternals verified when I set the filter to "Temporary ASP.NET Files". So I then set the filter to CSC.EXE, and noted that it was failing with ACCESS DENIED on C:\Windows\Temp\RES6.TMP running under NT AUTHORITY\NETWORK SERVICE. In the C:\Windows folder, there was a TEMP folder, and a TEMP.DELETETHIS folder. The ACL on the TEMP.DELETETHIS folder had an ACE for NETWORK SERVICE, but the ACL on the TEMP folder did not. The creation date of the new TEMP folder was roughly 1 week ago. So it appears that the installation of ASP.NET added an ACE on the original TEMP folder that would allow ASP.NET / NETWORK SERVICE to do what it needed to do. However, when someone decided they wanted a new TEMP folder on the server, the new TEMP folder inherited the permissions from WINDOWS and as such an ACE for NETWORK SERVICE was not placed on the new folder. Renaming TEMP to TEMP.HOLD and renaming TEMP.DELETETHIS back to TEMP solved the problem. Definitely an argument for better change control on the servers, as well as potentially further restricting access. But much of that is beyond my control...

At any rate... the first hit in a google for CS0016 takes you to the MSKB which almost nails it on the head, but in this case winds up kind of bending the nail so you have to take the hammer and try to pound the nail upright again, and then... er... nevermind.

An Assembly is a Page?

I spent the better part of the day chasing down what was ultimately a check-box in Internet Explorer's Advanced options. Blech.

The problem was that IE was failing to load a user control, and not being very helpful in determining why the control wouldn't load.

The control would load properly using HTTP, but would fail under HTTPS. Sysinternals' Filemon and Regmon showed no anomalous behavior. Debugging with cordbg wasn't particularly useful - the information wasn't really pointing me anywhere. The IEHOST log file (http://support.microsoft.com/?kbid=313892) didn't provide much more than the fusion log, which contained:
*** Assembly Binder Log Entry (xx/yy/zzzz @ aa:bb:cc QM) ***

The operation failed.Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\fusion.dll
Running under executable C:\Program Files\Internet Explorer\iexplore.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: Where-ref bind. Location = https://localhost/path/assemblyname.dll
LOG: Appbase = https://localhost
LOG: Initial PrivatePath = bin
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===

LOG: Processing DEVPATH.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL https://localhost/path/assemblyname.dll
LOG: All probing URLs attempted and failed.

And yet the IIS log was showing that the assembly was being requested and returned successfully to the client.

Eventually, I encountered the following KB article:"How to run a user control assembly that is hosted on Internet Information Services (IIS) in Internet Explorer"
http://support.microsoft.com/?kbid=892466
which states:

"To successfully download a user control under these conditions, the client setting for the Do not save encrypted pages to disk setting must be cleared."

Simply clearing that check box allowed IE to download and instantiate the control.

Grumble.