UE can corrupt Windows if uedit32.ini is in Windows dir and using backup/restore feature

Stefan_E · Mar 28, 2009#12009-03-28T19:24+00:00

A bit over two weeks ago (on March 13th) I've informed IDM Support about the following extremely dangerous bug in Ultraedit 14.20.1.1001 (and possibly other versions):

The menu option Advanced / Backup/Restore User Customizations allows you to backup and restore configuration settings
What is backed-up is grouped into 6 groups, the last one being called Others
If one selects Others (or Select All), UE includes all files in the directory where the file uedit32.ini resides.
- The location of the file can be determined through Avanced / Configuration / Application Layout
- By default, this file resides in %appdata%/IDMComp/UltraEdit
- However, uedit32.ini can also reside in C:/Windows. In this case, UE backs up all files in C:/Windows
If such a user customization is restored (again by selecting Others or Select All), it will overwrite any file (.ini, .dll, .exe, anything!) in C:/Windows, regardless of whether it belongs to UE or not. It is easy to see that such a step can corrupt your Windows if
- some of the files have been updated by other applications between when the UE backup and restore was performed
- a configuration is moved to another computer, where uedit32.ini resides in C:/Windows
So we need understand, why uedit32.ini sometimes resides in C:/Windows
- if you freshly install UE 14.20 on a new machine, it doesn't seem to happen (although it is of course IDMs task to guarantee that, not mine!)
- but if you had old versions of UE installed, they placed the uedit32.ini file in C:/Windows. It appears that the installation procedure of UE 14.2 preserves this location.
  - I upgraded from 10.20d directly to 14.20.1.1001 and certainly found my .ini file at the wrong location
  - even formally uninstalling the old version did not fix the issue; I needed manually delete C:/Windows/uedit32.ini to get a clean fresh install
  - I can't make a statement on what happens if the upgrade history starts or contains any of the 11.x, 12.x, 13.x versions as I don't have them to check

Needless to say, that this is extremely dangerous behavior. On top of this, I'm deeply disappointed on IDMs handling of the case:

They confirmed the seriousness the same day and promised to come back on the issue. Not until today!
I proposed them to notify the users on this bulletin board. Their reaction:
Our forums are user-to-user forums so we would not put any sort of notice on the forums. I did escalate the issue to our senior tech support staff member and he is currently in discussions about this with our lead engineer.
I was expecting quick action with a patch at least disabling the menu option Advanced / Backup/Restore User Customizations - not until today. (Note that the same functionality in an apparent safe form is available through the menues Advanced / Export Settings..., so they wouldn't even loose functionality!)
it might also be adequate to update the power tip at http://www.ultraedit.com/support/tutori ... tings.html
I also proposed a mailing to all registered customers who upgraded from a version which stored uedit32.ini in C:/Windows - at least I didn't get such a mail

I leave it to the reader as to how to interpret this performance. I gave them two weeks to act - I now feel it my duty to no longer hold this information back!
I would hope that we'll get immediately a step-by-step instruction from them as to how to bring our machines in a safe state!

Mofi · Mar 29, 2009#22009-03-29T13:38+00:00

Okay, some paragraphs about history, especially about application data files on Windows operating systems for a better understand why that happened what unfortunately happened.

Since v10.20 UltraEdit creates the default uedit32.ini and MOST other and since v14.00 ALL user configurable application related data files in %appdata\%IDMComp\UltraEdit on first start as long as there is an environment variable APPDATA (Windows NT4, Windows 2000, Windows XP, etc., but not Windows 95, Windows 98, ...). But if there is an uedit32.ini, uedit32.kbd, ... from a pre v10.20 release of UltraEdit in one of the directories where UltraEdit finds uedit32.ini automatically, then this INI and its location is used further.

In help of UltraEdit on page INI File Selection and Advanced Settings it is documented which options a user has to control the location and name of the INI file and the other user configurable application related data files which must be in the same directory as the INI file and in which order UltraEdit searches for the INI file.

For example you can read that UltraEdit searches for uedit32.ini in the directory of UltraEdit too. So I moved long time ago (I think it was v8.20) all UltraEdit related data files into the directory of UltraEdit which has the big advantage for me to be able to easily backup whole UltraEdit - program files with the data files with my settings. I need this because like IDM support from time to time I answer questions for users not using the currently latest version and then it is very practical to simply rename the program directory of UltraEdit and restore from an archive the older version, start it and try to find and an answer for the user with that older version.

Of course handling application data files in the program directory are by default not what Microsoft NOWADAYS allows for security and because that method does not support multiple users on the same computer. The Microsoft standard for Windows 95/98 (single user operating system) was that any program which used the MFC functions for reading from and writing to an INI file strings and numbers have automatically used a file in %windir% named like the applications file name, but with the file extension INI instead of EXE. So a Windows application developer has had nothing to develop for handling the INI file by itself. The MFC functions created the INI file in the directory which Microsoft has intended for application data files, write to it and read from it.

The change of the policy of Microsoft starting with Windows NT4 (a multi user operating system) was now a big problem for all applications used that MFC functions and of course should support Windows 95/98 parallel to NT4. Microsoft itself solved that problem by moving more and more into the registry. A policy I don't like because it is very hard to backup settings of an application stored in the registry. However, IDM offers also to store the settings in the registry instead of an INI file for those users which like the Microsoft philosophy which has surely also some advantages. The affect on saving everything in the registry, even histories, logs, help texts, etc. can be seen when comparing the size of the whole registry. If I export whole registry of my Windows 98 with all programs I needed installed to a text file, the file has about 6 MB. If I do the same on my Windows XP with all my programs installed, the file has already 25 MB (the ASCII version, not the UTF-16 LE version). And the registry export of my new computer with Vista Business and currently only the drivers installed has more than 200 MB. (One of the things that I want to find out on my new Vista computer before really start working with it: Why has it so a large registry?) You need to know that whole registry is loaded into RAM on Windows startup, of course in a more compact format than the text file export has. However, you can see why Vista needs more RAM.

Okay, back to handle settings in files instead of the registry as many shareware and freeware programs do, especially those which exist also for other operating systems, because there is no registry on Linux or MAC OS. Windows NT4 as well as Windows 2000 was now real problem for the developers of applications using an INI file, because these operating systems supported still the creation, writing and reading of INI files in the Windows directory. Also Windows XP used most of the time, especially in the beginning until 2005 or so, with administrator accounts supported the original INI file handling mechanism of Windows 95/98. So there was no real need for applications with a long Windows history and supporting all operating systems from Win98 to WinXP to change something on how the settings are stored. I think, starting in year 2005, more and more security has become important and especially companies started with using only restricted user accounts. With Vista many "old" applications needed to be reworked on the mechanism how and where to save the user settings of the application. And this process is still not finished for most applications, except the complete new ones which ignore their application history or simple do not have an application history because the application is really new.

I like UltraEdit because it is so highly customizable and that includes also how and where the user settings are stored. It is possible to use the registry for those users which like that. It supports the Microsoft default for the multi-user Windows versions with the user specific application data directory. But UE still supports also the single user philosophy, especially with the data files stored in the program directory. I personally never liked the Microsoft philosophy with the INI files in the Windows directory. So nearly all my programs on Windows 98 have their INI file in the program directory. But also supported is a completely customized data files storage mechanism with environment variable UEINIDIR which is for example good for a single user computer with multiple Windows versions. It is even possible to use just for a project a different INI file and depending on the directory of the INI also a project specific menu, toolbar, key assignments, etc. by starting UltraEdit with the /I="..." command line option which I still use for some of my projects.

So it is completely up to you. Setup whatever you like - see help page INI File Selection and Advanced Settings and the forum topics UltraEdit INI file location and How to transfer configuration settings to a new PC.

Well, it is surely not OK that UltraEdit simply packs all files of the directory with the INI into the backup and restores it if the INI is in the Windows directory. The problem is that Other is for all other files created by the user in the application data directory. The dialog lists all the files in this directory - in my case among some of my files also all the UltraEdit program files because the directory of the INI (the application data directory) is the UE program directory. So you have the possibility to select which OTHER files will be included in the backup and which not.

Maybe to avoid the indeed very dangerous and critical situation you have described it would be a good idea that UltraEdit would check if the directory of the INI file is the same as the directory stored in environment variable WINDIR. If this is the case Other should not be available for backup. Would you suggest that IDM?

Stefan_E · Mar 29, 2009#32009-03-29T16:08+00:00

Mofi, thanks for your detailed explanation of the Windows history. Indeed, I'm a happy customer since UE 6.0 and I stayed with 10.2 for quite a while. I also am still running an old machine (Pentium 4), where I started with UE pre-10.20 - with ~2 million licenses out there, I'm hardly the only one in this situation!

Maybe to avoid the indeed very dangerous and critical situation you have described it would be a good idea that UltraEdit would check if the directory of the INI file is the same as the directory stored in environment variable WINDIR. If this is the case Other should not be available for backup. Would you suggest that IDM?

Would I suggest this to IDM? Well - no: They promised well over two weeks ago to discuss this issue seriously internally and come back; they didn't. It's their product. (Ironically enough, the Others concept also doesn't work in a clean 14.20 installation: If everything is in %appdata%, it will also backup uedit32.reg. If I share the resulting .uec file with you, either I screw up your registration, or you become me... hardly something they can ever legally prosecute as a license violation!

I upgraded to 14.20 just before XMas; I never had problems with UE, but since then, I had to report five bugs - four of them could lead to lost work, since either UE freezes or overwrites edited files without asking. One of them is what we discuss here. All are confirmed by IDM support. None has been resolved (for one, a work-around was given...).

mjcarman · Mar 30, 2009#42009-03-30T22:03+00:00

Stefan_E wrote:The Others concept also doesn't work in a clean 14.20 installation: If everything is in %appdata%, it will also backup uedit32.reg. If I share the resulting .uec file with you, either I screw up your registration, or you become me... hardly something they can ever legally prosecute as a license violation!

This is not a bug. The purpose of the feature is to backup and restore your settings, not to allow you to share them with other users. You should want UE to backup and restore your registration.

Stefan_E wrote:I upgraded to 14.20 just before XMas; I never had problems with UE, but since then, I had to report five bugs - four of them could lead to lost work, since either UE freezes or overwrites edited files without asking. One of them is what we discuss here. All are confirmed by IDM support. None has been resolved (for one, a work-around was given...).

Good grief, cut 'em a little slack! While I'm sure that the issues you've reported are enormously important to you, IDM has more to worry about than any particular user. As a rule their tech support is highly responsive and bugs are fixed extremely quickly (relative to other commercial products).

By the way -- when you find a problem, the best thing you can do is to provide clear and complete instructions for reproducing it in your report. The easier it is for IDM to reproduce the faster the underlying problem can be identified and corrected. If it can't be reliably reproduced the chances of it getting fixed drop off dramatically.

Stefan_E · Mar 31, 2009#52009-03-31T19:00+00:00

By the way -- when you find a problem, the best thing you can do is to provide clear and complete instructions for reproducing it in your report. The easier it is for IDM to reproduce the faster the underlying problem can be identified and corrected.

I can guarantee you that each and every bug of the ones I mentioned I reported in a format which is

easily reproducible (one bug makes UE hang by editing a one-line file!)
the behavior is confirmed by their 'support' to be reproduced on their side

I don't know what makes you assume that this was any other? I would agree though that these are cases from a 'test drive' of the new version, not from practical use. So you are right in assuming that the overall relevance is relatively low (except for what I discuss in this thread). But they still shatter the trust in a buggy product update.

Maybe I should be thankful to all these bugs, since they stopped me from installing 14.20 on another machine, which I would then certainly have killed by transferring the customizations. Well, I can tell you that there are limits to my enjoyment here ...!

The purpose of the feature is to backup and restore your settings, not to allow you to share them with other users. You should want UE to backup and restore your registration.

I can only say that I prefer to deal with registration information in a bit a more careful and confidential way than have it arbitrarily float around in a potential whole bunch of files. But maybe that's just me...

mjcarman · Apr 01, 2009#62009-04-01T00:28+00:00

Stefan_E wrote:I can guarantee you that each and every bug of the ones I mentioned I reported in a format which is easily reproducible [and] the behavior is confirmed by their 'support' to be reproduced on their side. I don't know what makes you assume that this was any other?

It was neither an assumption nor an accusation, just general advice. The average end-user doesn't know how to report problems with much more detail than "X doesn't work!" which is a nightmare for support. Until a bug can be reproduced reliably it's virtually unfixable. If your bug reports are that detailed, great! You'll make Troy and crew very happy. If they're of the "X is broken!" variety you shouldn't expect much.