Dev to Mozilla: Please dump ancient Windows install processes Security bod Stefan Kanthak is asking Mozilla to quit using Windows self-extracting installs. Last week, Kanthak posted to Full Disclosure that Mozilla's SETUP.EXE package has a long-standing bug that allows privilege escalation for local users. “SETUP.EXE loads SHFOLDER.DLL ['] from a temporary (sub)directory "%TEMP%\7zS<hex …
"When some shops have the same username and password for all employees across the board, then, to answer your question, yes."
In which case, you don't need anything else for privilege escalation.
As this issue DOES NOT require access to System32, the whole argument is moot. The issue does require some odd system management practices though
This exploit requires access to the System32 folder
No, it doesn't. That's precisely Kanthak's point. You did read his original BUGTRAQ post, right? (If not, why do you think you're in a position to contradict him?)
Mozilla's setup loads shfolder.dll from a temporary directory, which it creates as part of the self-extraction process. That means there's an exploitable TOCTOU race.
Kanthak reminds everyone to turn off code execution in all ”%TEMP%” directories and their subdirectories
I always thought that planting an executable in a Temp folder was a sure sign of dodgy software. It's a shame and just a little disconcerting to find companies that should know better doing just that : in my case Avira, HP and Microsoft.
Perhaps Kanthak should have a word with these novices.
This is remarkably common. I was struck by the article's suggestion that %TEMP% should be non-executable because, in my experience, that means that at least half of all packages fail to install. Any sysadmin who wants to lock down %TEMP% in this way has my admiration and sympathy in equal measure. They'll be getting a lot of support calls from their users.
You're probably right about packages failing to install. To be honest, I'm not that bothered about an installer using %TEMP% temporarily as long as it cleans up after itself.
I'm mostly concerned about the behaviour of the likes of Avira, which seems to use %TEMP% to plant a persistent bit of code, nothing to do with installation. It suggests a desire to hide the code and doesn't exactly inspire trust.
You are somewhat correct... MANY installers will fail due to this old style installer way of doing things. My own practice in endpoint security implementation is to always prevent running programs from TEMP and DOWNLOAD folders, as those are the major entry points for malware.
I have found that for Firefox, I have to download the full install package and use a tool (7-zip, for example) to extract the installation files to an alternate folder for installation. Not difficult for someone who is in or well-acquainted with IT, but for most office task workers, this is a non-starter.... but those users should never be allowed to install programs anyway if you like security... lol.
Never let an application vendor guide your security policy. Good vendors will be able to adapt to fit within it, or they should be excluded from your environment.
Perhaps Kanthak should have a word with these novices.
BUGTRAQ readers know that Kanthak has already had a ... handful, shall we say ... of words for Microsoft. His "Defense in depth -- the Microsoft way" series of name-and-shame exploits is now up to number 33 (as of September).
The whole idea of installing software via an EXE is out dated. You have no idea what the EXE is going to do. Once you have to give the EXE permission to make changes to your system, then you are at it's mercy.
I don't know how you feel about Windows, but personally, I'm sick of it. It's a constant battle, Windows is always doing something that I don't want it to do and it always does things without my permission. I'm constantly removing stuff from scheduled tasks, the registry run location, startup and services. Every-time I run a setup.exe, I then have to search my system to see what the hell it added and changed to my system.
I use Linux at home and I don't have any of these issues, but at work I have to manage hundreds of Windows machines. We use the standard Windows tools like SCCM, group policy etc. I wonder if anyone else here feels the same way, but I always dream of being able to SSH to a PC here at work and just simply typing in 'sudo apt-get blah blah' to install software while the user is still logged on doing their work (and without reboot).
"Once you have to give the EXE permission to make changes to your system, then you are at it's mercy."
The same goes for anything that might include an executable, such as a MSI file that has helper DLLs or an NSIS installer that uses plug-ins. It's 2015 and the closest we've got to a trustworthy software installation method on Windows is "install KDE for Windows and hope that the package you want is in a repository".
Yes, because Linux packages don't run executable scripts (which in turn may run executables), don't they? Face it - a setup needs to alter the system, sometimes in deep ways (i.e. installing a driver), the setup writer has farily big privileges. But the article is about something you can achieve with any installer, good one which are tricked into loading a malicious DLL.
Yes, because Linux packages don't run executable scripts (which in turn may run executables), don't they?
Rarely. But you can always check to see what they're going to do *before* you do the installation.
Face it - a setup needs to alter the system, sometimes in deep ways (i.e. installing a driver)
That's why you have a single utility to do it, and have the package simply supply the data in a readable format to that utility.
Vic.
> It's 2015 and the closest we've got to a trustworthy software installation method on Windows is "install KDE for Windows and hope that the package you want is in a repository"
Not exactly. I know this won't be well-received around here but there is an alternative and it's "install from the Windows Store".
Actually, in Windows the way you should install software is Windows Installer and msi files - which has a fairly larger control on what installers do.
Then there's also the luser developer who thinks it's a good idea to litter your system with useless services and startup items - it's not a Windows problem, it's a developer attitude developed back in the old days and never changed - I agree MS could do better to stop crappy code to run, but then many users of said code would complain.
Anyway, even under any Debian you can't apt-get to install/upgrade any software because commercial software has a good chance of not being distributed through any repository, so you have to manage it yourself anyway. Also, under Debian, just using the standard repo may mean to use really outdate software.
Once MS moves everybody to its own app store you could achieve something like this - but is this really what you want?
"I don't know how you feel about Windows, but personally, I'm sick of it. It's a constant battle,"
It's way too labour intensive and always demanding your attention for something or other.
Typical OS X application installation: Drag to /Applications. Progress bar. Done.
Typical Linux application installation: sudo apt-get/zypper/yum. Progress log. Done.
Typical Windows application installation: Prompt, prompt, prompt, prompt, prompt, and then a final prompt called 'Finish', which may itself churn for ages. Possibly reboot required as well.
Like I said, too labour intensive. Like a spolied child: Me, me, me, me, ad infinitum.
Which seeds itself into all sorts of nooks and crannies on the HDD[1]. I don't know about the newst version but older ones created a hash that included the HDD serial number thus stopping you from restoring it from a TM backup onto a replacement HDD.
[1] I use the Term HDD to mea either a spinning rust drive or some form of Flash storage be it SATA-SSd or PCI-E Drives.
Typical Windows application installation: Prompt, prompt, prompt, prompt, prompt, and then a final prompt called 'Finish', which may itself churn for ages. Possibly reboot required as well.
Perhaps, for home users. Most installers have command line switches that you may not have bothered to use. Not so much for enterprise environments. There, everything should be done in the background. At the very most, a notice that some new feature is being set up on some user's machine on an ad hoc basis because of licensing issues is acceptable.
As far as running files from the temp directory is concerned, it is typical of malware to do so, therefor it should be blocked. It is that simple. Likewise, restricting admin accounts access to the internet and to email is useful because those are more properly things that a regular user account should do. Too, if Mozilla's install process under Windows is an issue, then Google's is even more so. The Chrome browser does not require admin rights to install and does so using fairly non-standard methods and locations. Regardless of the quality (or lack thereof) of the software, doing that sort of thing just makes life difficult for anyone trying to maintain large numbers of machines.
The problem is Windows has fairly powerful setup generators since Windows 3.x times. That lead someone to design overly complicated setups - they became far less complex today anyway (sometimes even too much).
Other OS use far less sophisticated tools. deb packaging is not that "developer friendly".
But I still prefer a setup let me input some configurations directly, instead of installing just a vanilla one and then require me to modify several conf files scattered here and there afterwards like some Linux software require (and some Linux software may prompt you as well).
If you need an unattended setup, a response file can be created to feed the prompts directly.
My end-user experience has a twist - it appears that if I allow the installer for FrogSpotter Plus to run FrogSpotter Plus for me before it closes, FrogSpotter Plus is typically running as Administrator.
I infer this because (1) the installer had to be and (2) my third-party touchscreen keyboard software can't type into FrogSpotter Plus, because the keyboard is only running as me.
This is wrong too, isn't it?
"if I allow the installer for FrogSpotter Plus to run FrogSpotter Plus for me before it closes, FrogSpotter Plus is typically running as Administrator."
I've come across a similar situation myself, though in my case it it led to file ownership problems.
Unfortunately some developers don't seem to test installations in non-administrator accounts (or maybe they did, but only several versions ago).
Oh, if only it were that easy. But apps (I'd say "real enterprise" if it wasn't so blatantly ridiculous) such as SalesForce don't even have a standard installer - just a web download that puts itself in %Temp% and installs into the user profile.
Central distribution? We can't have that, we need to be able to update our cloud app whenever we want, customer testing be damned.
And so we're all still allowing execution from %Temp% and AppData, which is effectively dropping daks, bending over a nearby table and being handcuffed to it with a sign saying "Please roger me with the spiked baseball bat behind you". Because the alternative is for no-one to be able to sell stuff and keep the business running.
But hey, what else can you do as a developer when those bloody admins insist on attempting to secure a machine? We have to do things the easiest way we can, security be damned!
F******g Spotify does that too. You should have heard the whining coming out of the Australian office after I GP banned executables from any of %temp% and Spotify stopped working. You'd think it was a mission critical application.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
