Blog

We recently encountered a terminal server user who said they were in Outlook and accidentally hit some keyboard combination that caused it to close.  When they tried to get back into Outlook it kept giving an error message.

When I connected and tried to run Outlook, it kept displaying an error message that there was no Outlook Profile setup.  However, when I checked the profiles there were in fact several profiles listed.  I tried creating a brand new profile, but still received the error message.

I had the user log off and back on to the terminal server, checked outlook from my account to make sure it wasn’t something server wide, and then I checked the actual outlook.exe under the Program Files directory.  I did not see anything checked for compatibility with my account, but when I checked the outlook.exe from her account, it had Compatibility Mode for Windows 95 checked. [more]

My assumption on what happened is that outlook crashed, came back up, and asked if it should be run in compatibility mode.  I am assuming the user said yes at this point, and it turned the option on which caused outlook to not work anymore.


 

I had looked at a problem with IE where the user worked frequently with data input into form fields.  The problem that they had was that it would not start giving the auto complete suggestions as they started typing. 

I checked Internet Options -> Content -> AutoComplete Settings and verified that the "Forms" option was checked.  Since it appeared that everything was enabled to do what the user wanted, I selected the "Delete AutoComplete history" option.  After clearing the history, the auto complete started working again. 

I am unsure whether or not the files containing the information for this feature were corrupt or possibly too large to continue working.


 

We had an ongoing issue with a customer’s HP server where the internal fans continually ran at full RPM. We had to move the server to a new location because the noise was too much for the employees. The HP monitoring software would shut down the server occasionally because it senses it over heating, but there was never any real sign or indication that there was an overheating issue. The problem typically occurred when backups were running so we thought it was possibly the tape drive was causing a faulty temperature reading.

We went as far as to purchase a USB temperature logger which I placed on the server to monitor the environment for a week.  All readings came back normal. I opened a case with HP Support and their recommendation was to update the firmware and the drivers and everything else they could think of. But nothing they suggested made a difference. [more]

I decided to take the server down and look at the internal parts for possible obstructions in air flow that would cause it to think it was overheating. I was checking the second processors heat sink I noticed it was not seated exactly right but was clamped down. I removed the heat sink and found dust under it. That’s right... dust between the CPU and the silver paste. As you can tell from the picture below the silver paste had never contacted the CPU, except on one corner. I grabbed some canned air, blew the dust off, and reseated the heat sink.  Closed up the server and started it up. Since that time the server has run super quite with no thermal issues to this day. However, HP did have to replace an internal fan that failed from running so long at high RPM.


 

A coworker and I have been doing a lot of work on the CommVault email archiving and compliance products here lately. CommVault email compliance solutions provide two ways to access data collected via email compliance archiving agents. The end-user compliance portal allows a user to log in and search only their email whereas the compliance portal allows search of all email that has been collected via journaling. The issue we were able to reproduce was the following:

A user with a specific employment date (lets say 10.1.2010 for instance) could log in and see email that was sent prior to his/her employment date. They couldn’t see ALL email, just certain email. [more]

Long story short, as part of a troubleshooting task with CommVault support, our customer had created  a “special” configuration that enabled the compliance agents to basically harvest all mail in the Exchange environment from all mailboxes. Part of the work that the CommVault indexing engine does is to look at the email message and “mark” the message in such a way that it can be found by associated parties via the end-user search portal. It does this by looking up all parties on the email in active directory, then it associates the message with all the user GUIDs that should have access to the message via end-user search. In our case specifically, when all the emails were “harvested” from all exchange mailboxes, a specific set of emails that were sent to a distribution group were pulled in. The indexing engine expands those distribution groups and links the GUIDs accordingly. Emails to that distribution group go back farther back in time than the employment of the user in question, but the user is CURRENTLY a member of the distribution group. So, when the indexing server expanded the group, that user was associated….and viola, access to an email prior to employment via end-user search.


 

If you forward a meeting invitation, Exchange will notify the meeting Organizer that the meeting notice has been forwarded, and to who it was forwarded.  So, if you don’t want the Organizer to know that their meeting was forwarded, you can forward the meeting as an attachment.

Notes:

  • When you forward a meeting request, it will not include the organizers name in the “To” or “CC”  fields; however, there is a small note above the “To” section that says “When you forward this meeting, a meeting forward notification will be sent to the organizer.”
  • If you look at the forwarded message (from your sent items), it does not show it was sent to the organizer; however, it does state in the From: Your Name on behalf of Person You Forwarded To.

 

Steve Gibson, one of the hosts of the popular "SecurityNow!" podcast, has created a tool that allows the checking of DNS servers for spoofability. This tool works by asking the user's browser to retrieve an image located at a uniquely named subdomain of the type xxxxxxxxxxxxx.dns.grc.com, "where the “xxxxxxxxxxxxx” is replaced with a unique 13-character string of characters that has never been used before."*

Then, in order to know the IP address for this special domain, the browser sends a DNS query to its DNS server, which then forwards this query to a special nameserver located at grc.com. This nameserver tells the DNS server that the location of that image is actually an "'alias' of the real domain name, which is a good deal longer and more complex."* The nameserver instructs the DNS server to look up the name of the "real" location of the image which looks like "...a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.xxxxxxxxxxxxx.dns.grc.com"* (with about 50 preceding 'a''s) [more]

The DNS server sends queries to the GRC nameserver, attempting to resolve the IP address of the given domain name one sub-domain at a time , causing the DNS server to send hundreds of requests which are collected by the GRC nameserver. As the nameserver collects these requests, it creates a scatter plot of both the Source Port and the Query Transaction ID of each request. Then, the data is analyzed to see the randomness of the Source Port and the Query Transaction ID which reveals the spoofability of the used DNS servers.

This tool is quite interesting, and shows that even as vulnerabilities arise on these critical systems, many do not fix the vulnerabilities, leaving the users at risk to visit a malicious web site believing that it is the site they were looking for which potentially places their private data at risk.

*A more thorough and detailed analysis of how this tool works can be found by reading GRC's article on how the DNS Nameserver Spoffability Test works.


 

I have been asked several times what my favorite Windows program is for accessing ISO images of CDs and DVDs.  To just browse an ISO and extract files, I prefer 7-zip.  To mount them as a drive letter I like MagicISO.  I am partial to tools that do not need installation, but of course something like this must install a driver, so it requires an installer.  This software is very lightweight.  The driver is only 250K and you only need to run the client to mount and dismount disc images. Some of these kinds of tools are used by gamers and others to make illegal copies of CDs and that software may be detected as malware, but MagicISO is still passing all antivirus scanners on Virustotal.


 
 

We had a new ESXi host to install recently with the latest 4.1, but the server didn’t have a disk (yet) for us to install it on. Fortunately, our Fiber Channel SAN had a spare LUN with some extra drives that we could use. I destroyed the LUN and the virtual disk and pulled out a spare drive to stick it into the new server. Simple enough and now we can install ESXi.

Well, not quite… [more]

When we started the installer, it would always hang on loading the storage drivers. No matter what version of ESX or ESXi we attempted to install, the application would hang before the software even had an opportunity to start installing and always at the storage drivers. After some discussion with one of the other engineers, I had an epiphany. Maybe that drive still had some remnants of the old RAID 5 array and the server was looking for the remaining disks. I booted the server to a SmartStart CD, fired up the Array Configuration Utility, destroyed and recreated the array, and attempted the reinstall of ESXi. Success!

Moral of the story: When repurposing a hard drive that was formally a part of an array, make sure to actually wipe the disk clean instead of simply destroying the array to completely verify that there are no longer any remnants of the former array configuration.

 


 

On January 3rd, 2011 Rick Regan reported on his blog Exploring Binary that the following statement causes PHP to hang in an infinite loop.

               <?php $d = '2.2250738585072011e-308'; echo $d; ?>

The problem occurred when the string '2.2250738585072011e-308' is converted to a double precision floating point number in a subroutine named zend_strtod().  The code takes a string that represents a floating point number and tries to return the nearest double precision floating point number.  A standard double precision floating point number is 64 bits wide: 1 bit for the sign, 11 bits for the exponent, and 52 bits for the fractional part.  The problem number written as a hexadecimal floating point constant looks like 0x0FFFFFFFFFFFFFp-1022.  This means the number is almost the smallest number that can be represented in 64 bits that is close to zero without being zero and the fractional part is all 1’s.  The routine zend_strtod() works by converting the string into an approximate floating point number and then tries to refine the approximation in successive loops.  The problem comes when the routine uses the 80 bit floating point registers in most Intel processors.  The 80 bit floating point registers are a legacy from the 8087 Floating Point Coprocessor that Intel introduced in 1980.  With the wider 80 bit hardware registers, the processor can represent more values between the problem number and zero.  The unwanted precision ended up causing the routine to loop endlessly trying to refine the approximate floating point number.  This “unwanted precision” has been at the root of many floating point bugs and it’s likely to show up again in other programs and operating system libraries. [more]

The solution chosen by the PHP committers was to mark the variables used in the refinement to be “volatile”. This causes the compiler to keep the values in memory and not use the hardware registers for comparison or arithmetic operations.

This bug has been fixed in PHP version 5.3.5 and 5.2.17 on January 6th, 2011.  Here is a link to a test script to determine if your version of PHP is affected by this bug http://www.php.net/archive/2011.php#id2011-01-06-1.