Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Joe Souza joe.so...@netmotionwireless.com wrote: It is at the very least ignorant to call Microsoft's CreateProcess behavior braindead. What else is it then? If anything it shows your complete lack of understanding of the issue. Really? Let's see how good your understanding of the Win32 API and its compatibility to the Win16 API is. The behavior of the API is not arbitrary; Microsoft has always had to walk the line between security and application compatibility. And every so often they made the wrong decision! If Microsoft were to change behavior of CreateProcess as you suggest, then they would break untold apps that have been written so as to call the API without quoting the target executable. Such crap deserves to break: better be safe than sorry. The quotes became necessary only with the advent of LFN-aware file systems, NTFS was LFN-aware, from its very beginning, 20+ years ago! and the Windows API predates the availability of LFN-aware file systems on Windows. Which Windows API? The Win32 API was introduced with Windows NT, together with the LFN-aware NTFS file system. It was INCOMPATIBLE to the previously used Win16 API, on source and binary level. There was no CreateProcess() in the Win16 API, but WinExec(). So: what about just getting the preconditions to your arguments right? OUCH^WPooof: ff you do, your arguments just vanish. If you were the developer of an operating system that millions of people relied upon and you were faced with the decision between tightening up the behavior of an API vs. breaking customer applications that people regularly use, what would your choice be? I dont need to choose! There was no compatibility to break. Stefan Original message From: Stefan Kanthak Date:07/30/2014 3:19 AM (GMT-08:00) To: Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble over unquoted paths the very instant they are used and poorly written programs with such beginners errors would not be delivered to hundreds of millions of unsuspecting users putting them at risk to run a rogue C:\Program.exe RE: 0. http://www.dwheeler.com/essays/filenames-in-shell.html This was brought up on the FD mailing list towards the end of June (http://seclists.org/fulldisclosure/2014/Jun/140) in which discussion on how the Linux shell has its own quirks regarding path names and potential security issues. It's disingenuous to single out Windows with its path name handling in this context without addressing this issue across the board. Simply put, these types of issues are universally understood across many operating systems to be in the realm of applications themselves and NOT a fault of the platform. Its but the fault of the platform! CreateProcess*() is just the system call, and its the ONLY system call available to start another process, used by ShellExecute*(), the service manager etc. pp. So again, to sit here and single out Windows for its quirky pathname behavior is just picking fights here. See above: you completely miss the point! In short, yes, Windows has a function that takes input and launches a path which COULD lead to unexpected behavior when passing the argument without quotes. But arguing that this should be on Microsoft to resolve within Windows just points me back towards the aforementioned link which says such problems should also be resolved at the OS layer for them as well. See above: CreateProcess*() is the OS layer here! To address your Windows
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Joe Souza joe.so...@netmotionwireless.com wrote: Stop sending HTML! In Win32, WinExec is merely a wrapper around CreateProcess. CreateProcess needs to support the same semantics that WinExec did. It does: the Win16 API does NOT support LFNs, just SFNs. With this precondition (which you did not take into account, again) WinExec() supports under Win32 exact the same semantics as under Win16. Stefan Original message From: Stefan Kanthak Date:07/30/2014 8:26 AM (GMT-08:00) To: Joe Souza , Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: It is at the very least ignorant to call Microsoft's CreateProcess behavior braindead. What else is it then? If anything it shows your complete lack of understanding of the issue. Really? Let's see how good your understanding of the Win32 API and its compatibility to the Win16 API is. The behavior of the API is not arbitrary; Microsoft has always had to walk the line between security and application compatibility. And every so often they made the wrong decision! If Microsoft were to change behavior of CreateProcess as you suggest, then they would break untold apps that have been written so as to call the API without quoting the target executable. Such crap deserves to break: better be safe than sorry. The quotes became necessary only with the advent of LFN-aware file systems, NTFS was LFN-aware, from its very beginning, 20+ years ago! and the Windows API predates the availability of LFN-aware file systems on Windows. Which Windows API? The Win32 API was introduced with Windows NT, together with the LFN-aware NTFS file system. It was INCOMPATIBLE to the previously used Win16 API, on source and binary level. There was no CreateProcess() in the Win16 API, but WinExec(). So: what about just getting the preconditions to your arguments right? OUCH^WPooof: ff you do, your arguments just vanish. If you were the developer of an operating system that millions of people relied upon and you were faced with the decision between tightening up the behavior of an API vs. breaking customer applications that people regularly use, what would your choice be? I dont need to choose! There was no compatibility to break. Stefan Original message From: Stefan Kanthak Date:07/30/2014 3:19 AM (GMT-08:00) To: Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble over unquoted paths the very instant they are used and poorly written programs with such beginners errors would not be delivered to hundreds of millions of unsuspecting users putting them at risk to run a rogue C:\Program.exe RE: 0. http://www.dwheeler.com/essays/filenames-in-shell.html This was brought up on the FD mailing list towards the end of June (http://seclists.org/fulldisclosure/2014/Jun/140) in which discussion on how the Linux shell has its own quirks regarding path names and potential security issues. It's disingenuous to single out Windows with its path name handling in this context without addressing this issue across the board. Simply put, these types of issues are universally understood across many operating systems to be in the realm of applications themselves and NOT a fault of the platform. Its but the fault of the platform! CreateProcess*()
RE: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
You can blame the Mail app on Android for the HTML. You have illustrated below exactly the reason why CreateProcess needs to handle unquoted paths. Thanks for helping me make my point. -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Wednesday, July 30, 2014 10:11 AM To: Joe Souza; Michael Cramer; Gynvael Coldwind Cc: fulldisclosure; Brandon Perry; bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: Stop sending HTML! In Win32, WinExec is merely a wrapper around CreateProcess. CreateProcess needs to support the same semantics that WinExec did. It does: the Win16 API does NOT support LFNs, just SFNs. With this precondition (which you did not take into account, again) WinExec() supports under Win32 exact the same semantics as under Win16. Stefan Original message From: Stefan Kanthak Date:07/30/2014 8:26 AM (GMT-08:00) To: Joe Souza , Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: It is at the very least ignorant to call Microsoft's CreateProcess behavior braindead. What else is it then? If anything it shows your complete lack of understanding of the issue. Really? Let's see how good your understanding of the Win32 API and its compatibility to the Win16 API is. The behavior of the API is not arbitrary; Microsoft has always had to walk the line between security and application compatibility. And every so often they made the wrong decision! If Microsoft were to change behavior of CreateProcess as you suggest, then they would break untold apps that have been written so as to call the API without quoting the target executable. Such crap deserves to break: better be safe than sorry. The quotes became necessary only with the advent of LFN-aware file systems, NTFS was LFN-aware, from its very beginning, 20+ years ago! and the Windows API predates the availability of LFN-aware file systems on Windows. Which Windows API? The Win32 API was introduced with Windows NT, together with the LFN-aware NTFS file system. It was INCOMPATIBLE to the previously used Win16 API, on source and binary level. There was no CreateProcess() in the Win16 API, but WinExec(). So: what about just getting the preconditions to your arguments right? OUCH^WPooof: ff you do, your arguments just vanish. If you were the developer of an operating system that millions of people relied upon and you were faced with the decision between tightening up the behavior of an API vs. breaking customer applications that people regularly use, what would your choice be? I dont need to choose! There was no compatibility to break. Stefan Original message From: Stefan Kanthak Date:07/30/2014 3:19 AM (GMT-08:00) To: Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble over unquoted paths the very instant they are used and poorly written programs with such beginners errors would not be delivered to hundreds of millions of unsuspecting users putting them at risk to run a rogue C:\Program.exe RE: 0. http://www.dwheeler.com/essays/filenames-in-shell.html
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Joe Souza joe.so...@netmotionwireless.com wrote: You can blame the Mail app on Android for the HTML. I dont: I but blame PEBKAC for the HTML or other deficiencies. You have illustrated below exactly the reason why CreateProcess needs to handle unquoted paths. Thanks for helping me make my point. Really? Where did I write that CreateProcess() should guess how many parts of the command line form the path to the application? You still dont get the point, you dont even read what I wrote. Stefan -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Wednesday, July 30, 2014 10:11 AM To: Joe Souza; Michael Cramer; Gynvael Coldwind Cc: fulldisclosure; Brandon Perry; bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: Stop sending HTML! In Win32, WinExec is merely a wrapper around CreateProcess. CreateProcess needs to support the same semantics that WinExec did. It does: the Win16 API does NOT support LFNs, just SFNs. With this precondition (which you did not take into account, again) WinExec() supports under Win32 exact the same semantics as under Win16. Stefan Original message From: Stefan Kanthak Date:07/30/2014 8:26 AM (GMT-08:00) To: Joe Souza , Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza joe.so...@netmotionwireless.com wrote: It is at the very least ignorant to call Microsoft's CreateProcess behavior braindead. What else is it then? If anything it shows your complete lack of understanding of the issue. Really? Let's see how good your understanding of the Win32 API and its compatibility to the Win16 API is. The behavior of the API is not arbitrary; Microsoft has always had to walk the line between security and application compatibility. And every so often they made the wrong decision! If Microsoft were to change behavior of CreateProcess as you suggest, then they would break untold apps that have been written so as to call the API without quoting the target executable. Such crap deserves to break: better be safe than sorry. The quotes became necessary only with the advent of LFN-aware file systems, NTFS was LFN-aware, from its very beginning, 20+ years ago! and the Windows API predates the availability of LFN-aware file systems on Windows. Which Windows API? The Win32 API was introduced with Windows NT, together with the LFN-aware NTFS file system. It was INCOMPATIBLE to the previously used Win16 API, on source and binary level. There was no CreateProcess() in the Win16 API, but WinExec(). So: what about just getting the preconditions to your arguments right? OUCH^WPooof: ff you do, your arguments just vanish. If you were the developer of an operating system that millions of people relied upon and you were faced with the decision between tightening up the behavior of an API vs. breaking customer applications that people regularly use, what would your choice be? I dont need to choose! There was no compatibility to break. Stefan Original message From: Stefan Kanthak Date:07/30/2014 3:19 AM (GMT-08:00) To: Michael Cramer , Gynvael Coldwind Cc: fulldisclosure , Brandon Perry , bugtraq@securityfocus.com Subject: Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Michael Cramer mike.cra...@outlook.com wrote: sudo make-me-a-sandwich.py How is this different from any other temporary, per-process elevation system? 0. neither sudo nor make-me-a-sandwich.py nor the OS where these programs typically run have a CreateProcess*() system call which guesses which executable it should run in case of a command line with embedded spaces. Do you expect that your command line executes sudo make-me-a-sandwich.py in the absence of a file sudo or sudo.exe? 1. if you omit sudo from the command line, there is no elevation, not even an attempt for an elevation. On Windows, you dont need to use sudo, you just open for example REGEDIT.EXE or make-me-a-sandwich.reg: if you do this in a standard user account REGEDIT.EXE will run with standard user rights, without any prompt for elevation. But if you do this in an administrator account (except the builtin Administrator), Windows prompts for consent. And if you use one of the 70 Windows programs which Microsoft in their very finite wisdom granted auto-elevation, you wont see any elevation prompt at all! 2. on *x, your user account is an UNPRIVILEGED user account, and you have to use sudo explictly. On Windows, all user accounts created during setup are administrator accounts which show the above mentioned behaviour. Is this enough of a difference? Sent from my Surface Pro 3 ARGH! I don't need any advertising! Stefan From: Stefan Kanthak Sent: ?Monday?, ?July? ?28?, ?2014 ?06?:?08 To: Gynvael Coldwind Cc: fulldisclosure, Brandon Perry, bugtraq@securityfocus.com Gynvael Coldwind wrote: So reading the links you provided I semi-agree with you. I think the problem boils down to this part of your initial e-mail: PS: yes, it needs administrative privileges to write C:\Program.exe. BUT: all the user account(s) created during Windows setup have administrative privileges. My point was (and it still stands) that if you have admin access, this isn't a privilege escalation, as there is no escalation part here. Correct. If only Microsoft would educate its users to exercise STRICT user separation and use different accounts for administration and daily work. This is where and why UAC chimes in (which answers your question below): Joe Average uses the administrative account created during Windows setup, but UAC strips the administrator rights. Microsoft sells UAC as Joe Average works with standard user rights or Joe Average is not an administrator any more, neglecting that Joe will happily approve almost every request for administrative rights (or isnt asked at all when one of the about 70 Windows executables which are exempt from the elevation prompt are auto-elevated). The links you provided use different wording, e.g. (http://blogs.technet.com/b/srd/archive/2013/07/09/assessing-risk-for-the-july-2013-security-updates.aspx): To exploit the vulnerability addressed by this update, attacker must have permission to create a new file at the root of the system drive. (C:\malicious.exe) This makes of course more sense, though as I did mention above, it does seem to require deliberate action from the administrator to actually allow a non-admin user the WD (add file to directory) privilege on C:\, which is rather rare I would say. Correct. This argument holds as long as strict user separation is exercised. But with UAC, Joe Average is both user and administrator, and isnt really aware of his split personality. That being said, after thinking about it again I do see your point, which I interpret at: even if an administrator grants all users WD/AD on C:\, there should be no reason for him to worry, as there is no reason to suspect files placed in C:\ are going to auto-execute on certain events*. * let's leave autoexec.bat/config.sys out of this, as that branch of Windows is long dead and supported only FAT anyway So let me change my initial e-mail to: Congratz on finding the bug :) (BTW not sure why did you bring UAC into the discussion - did I miss something? or was it just an argument you've heard before and wanted to reply to it preventively?) Cheers! regards Stefan On Fri, Jul 25, 2014 at 2:50 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Gynvael Coldwind wrote: Well it was discussed a couple of times recently on FD that this is a bug, but it's not a privilege escalation. If you are admin (and you did mention that it's a prerequisite) you can execute code as other users anyway - so there's no *escalation* here. Therefore it's not a security bug (unless you are using a super old version of Windows with incorrect ACLs on c:\, which sounds like a bug in itself), just a normal bug. Not sure if FD is the right place for non-security bugs tbh. If these bugs were no security bugs: why does Microsoft then publish fixes for (at least some of) them via MSRC bulletins and Windows Update?
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Michael Cramer mike.cra...@outlook.com wrote: I think you're arguing semantics here. Of course. Of course the specifics of how a particular program is executed will be different between command line and GUI-based OS'. Really? Is there any need for this difference you state? BTW: what is the difference? Both provide the ability for non-privileged users to launch processes with specific, temporary Administrative access rather than their account having always-on Administrative access. But only Windows' system call CreateProcess*() has the COMPLETELY BRAINDEAD behaviour to guess or probe which executable to run! Whether or not a user is going to click yes to everything is completely irrelevant to the technical details at hand. It could be argued that training a user to type 'sudo' on every command could have the same effects. Just because *YOU* understand the difference doesn't mean there aren't 1000 Linux users out there typing sudo for literally everything simply because that's how they were taught to type commands in the terminal. You miss the point, completely. It's not about sudo or RUNAS.EXE or UAC, its about the braindead behaviour of CreateProcess*(). This is the culprit. Nothing else. Without its braindead behaviour every developer or his QA would stumble over unquoted paths the very instant they are used and poorly written programs with such beginners errors would not be delivered to hundreds of millions of unsuspecting users putting them at risk to run a rogue C:\Program.exe RE: 0. http://www.dwheeler.com/essays/filenames-in-shell.html This was brought up on the FD mailing list towards the end of June (http://seclists.org/fulldisclosure/2014/Jun/140) in which discussion on how the Linux shell has its own quirks regarding path names and potential security issues. It's disingenuous to single out Windows with its path name handling in this context without addressing this issue across the board. Simply put, these types of issues are universally understood across many operating systems to be in the realm of applications themselves and NOT a fault of the platform. Its but the fault of the platform! CreateProcess*() is just the system call, and its the ONLY system call available to start another process, used by ShellExecute*(), the service manager etc. pp. So again, to sit here and single out Windows for its quirky pathname behavior is just picking fights here. See above: you completely miss the point! In short, yes, Windows has a function that takes input and launches a path which COULD lead to unexpected behavior when passing the argument without quotes. But arguing that this should be on Microsoft to resolve within Windows just points me back towards the aforementioned link which says such problems should also be resolved at the OS layer for them as well. See above: CreateProcess*() is the OS layer here! To address your Windows auto-elevated processes. Yes, this is the default configuration when these processes are signed binaries from a specific Microsoft certificate. However, for the security conscious folks you can easily turn UAC up to the maximum level which will require elevation on the secure desktop for all applications, including these processes. This was the default configuration in Windows Vista when it was released, but enough people complained about it that Microsoft reduced the # of UAC prompts in Windows 7 with the above resolution. Yes. An that's another completely braindead decision. Instead of fixing their own buggy programs they built one more crappy workaround. All user accounts in Ubuntu are created with the ability to use sudo automatically without further configuration from the root account. All exec*() calls not only on Ubuntu DONT show the braindead behaviour of Windows CreateProcess*(). regards Stefan Sent from my Surface Pro 3 From: Stefan Kanthak Sent: ?Monday?, ?July? ?28?, ?2014 ?10?:?43 To: Michael Cramer, Gynvael Coldwind Cc: fulldisclosure, Brandon Perry, bugtraq@securityfocus.com Michael Cramer mike.cra...@outlook.com wrote: sudo make-me-a-sandwich.py How is this different from any other temporary, per-process elevation system? 0. neither sudo nor make-me-a-sandwich.py nor the OS where these programs typically run have a CreateProcess*() system call which guesses which executable it should run in case of a command line with embedded spaces. Do you expect that your command line executes sudo make-me-a-sandwich.py in the absence of a file sudo or sudo.exe? 1. if you omit sudo from the command line, there is no elevation, not even an attempt for an elevation. On Windows, you dont need to use sudo, you just open for example REGEDIT.EXE or make-me-a-sandwich.reg: if you do this in a standard user account REGEDIT.EXE will run with standard user rights, without any prompt for elevation. But if you do this in an administrator account
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
So reading the links you provided I semi-agree with you. I think the problem boils down to this part of your initial e-mail: PS: yes, it needs administrative privileges to write C:\Program.exe. BUT: all the user account(s) created during Windows setup have administrative privileges. My point was (and it still stands) that if you have admin access, this isn't a privilege escalation, as there is no escalation part here. The links you provided use different wording, e.g. (http://blogs.technet.com/b/srd/archive/2013/07/09/assessing-risk-for-the-july-2013-security-updates.aspx): To exploit the vulnerability addressed by this update, attacker must have permission to create a new file at the root of the system drive. (C:\malicious.exe) This makes of course more sense, though as I did mention above, it does seem to require deliberate action from the administrator to actually allow a non-admin user the WD (add file to directory) privilege on C:\, which is rather rare I would say. That being said, after thinking about it again I do see your point, which I interpret at: even if an administrator grants all users WD/AD on C:\, there should be no reason for him to worry, as there is no reason to suspect files placed in C:\ are going to auto-execute on certain events*. * let's leave autoexec.bat/config.sys out of this, as that branch of Windows is long dead and supported only FAT anyway So let me change my initial e-mail to: Congratz on finding the bug :) (BTW not sure why did you bring UAC into the discussion - did I miss something? or was it just an argument you've heard before and wanted to reply to it preventively?) Cheers! On Fri, Jul 25, 2014 at 2:50 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Gynvael Coldwind wrote: Well it was discussed a couple of times recently on FD that this is a bug, but it's not a privilege escalation. If you are admin (and you did mention that it's a prerequisite) you can execute code as other users anyway - so there's no *escalation* here. Therefore it's not a security bug (unless you are using a super old version of Windows with incorrect ACLs on c:\, which sounds like a bug in itself), just a normal bug. Not sure if FD is the right place for non-security bugs tbh. If these bugs were no security bugs: why does Microsoft then publish fixes for (at least some of) them via MSRC bulletins and Windows Update? See https://technet.microsoft.com/library/security/ms13-058.aspx or https://technet.microsoft.com/library/security/ms13-034.aspx Or pulls drivers whose setup routines show these bugs from Windows Update? See http://seclists.org/fulldisclosure/2014/May/40 Also try to see these bugs as a blended threat: * during Windows setup Microsoft still creates all user accounts as administrators. * Microsoft sells its unsuspecting users UAC as a security feature, but does NOT inform them (or at least does not inform Joe Average) that UAC is not a security boundary and they should better use a restricted^Wstandard user account instead of the administrator account created during setup. * Joe Average will happily give consent to any program which presents an UAC prompt to him: he wants to get his work done, and this UAC prompt is just an annoyance. BTW: when Windows asks him for consent, this must be right? regards Stefan Cheers, On 25 Jul 2014 00:46, Stefan Kanthak stefan.kant...@nexgo.de wrote: Brandon Perry wrote: So, I am very curious how you are finding these? Have you automated this or is it manual hand work? All my Windows installations have http://home.arcor.de/skanthak/download/SENTINEL.EXE and http://home.arcor.de/skanthak/download/SENTINEL.DLL preinstalled as C:\Program.exe and C:\Program.dll, so I'm notified when some poorly written program tries to execute them. The sentinels call MessageBox() with MB_SERVICE_NOTIFICATION, so the messages are recorded in the event log too where I can find them later. I also preinstall an APPINIT.DLL https://support.microsoft.com/kb/197571 which logs all command lines of programs linked to USER32.DLL to a file: filtering for C:\Program at column 1 lists all the culprits. My third source is a SAFER.Log https://technet.microsoft.com/cc786941.aspx where every execution attempt is logged, including the executables caller: filtering this for \program.exe or \program.dll lists all the culprits. So basically I just have to sit and wait... In case one of my customers was hit, and this did not happen during an installation, I have to interrogate them what they did... and hope they can remember with sufficient detail. But almost all hits occur during installations or the customization following an installation (here it was the import of existing mails into a new account), so these are not so difficult to reproduce. regards Stefan PS: of course it helps if 8.3 names are disabled and C:\Program Files\ can't be aliased as C:\Progra~1\ To
Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account
Gynvael Coldwind wrote: So reading the links you provided I semi-agree with you. I think the problem boils down to this part of your initial e-mail: PS: yes, it needs administrative privileges to write C:\Program.exe. BUT: all the user account(s) created during Windows setup have administrative privileges. My point was (and it still stands) that if you have admin access, this isn't a privilege escalation, as there is no escalation part here. Correct. If only Microsoft would educate its users to exercise STRICT user separation and use different accounts for administration and daily work. This is where and why UAC chimes in (which answers your question below): Joe Average uses the administrative account created during Windows setup, but UAC strips the administrator rights. Microsoft sells UAC as Joe Average works with standard user rights or Joe Average is not an administrator any more, neglecting that Joe will happily approve almost every request for administrative rights (or isnt asked at all when one of the about 70 Windows executables which are exempt from the elevation prompt are auto-elevated). The links you provided use different wording, e.g. (http://blogs.technet.com/b/srd/archive/2013/07/09/assessing-risk-for-the-july-2013-security-updates.aspx): To exploit the vulnerability addressed by this update, attacker must have permission to create a new file at the root of the system drive. (C:\malicious.exe) This makes of course more sense, though as I did mention above, it does seem to require deliberate action from the administrator to actually allow a non-admin user the WD (add file to directory) privilege on C:\, which is rather rare I would say. Correct. This argument holds as long as strict user separation is exercised. But with UAC, Joe Average is both user and administrator, and isnt really aware of his split personality. That being said, after thinking about it again I do see your point, which I interpret at: even if an administrator grants all users WD/AD on C:\, there should be no reason for him to worry, as there is no reason to suspect files placed in C:\ are going to auto-execute on certain events*. * let's leave autoexec.bat/config.sys out of this, as that branch of Windows is long dead and supported only FAT anyway So let me change my initial e-mail to: Congratz on finding the bug :) (BTW not sure why did you bring UAC into the discussion - did I miss something? or was it just an argument you've heard before and wanted to reply to it preventively?) Cheers! regards Stefan On Fri, Jul 25, 2014 at 2:50 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote: Gynvael Coldwind wrote: Well it was discussed a couple of times recently on FD that this is a bug, but it's not a privilege escalation. If you are admin (and you did mention that it's a prerequisite) you can execute code as other users anyway - so there's no *escalation* here. Therefore it's not a security bug (unless you are using a super old version of Windows with incorrect ACLs on c:\, which sounds like a bug in itself), just a normal bug. Not sure if FD is the right place for non-security bugs tbh. If these bugs were no security bugs: why does Microsoft then publish fixes for (at least some of) them via MSRC bulletins and Windows Update? See https://technet.microsoft.com/library/security/ms13-058.aspx or https://technet.microsoft.com/library/security/ms13-034.aspx Or pulls drivers whose setup routines show these bugs from Windows Update? See http://seclists.org/fulldisclosure/2014/May/40 Also try to see these bugs as a blended threat: * during Windows setup Microsoft still creates all user accounts as administrators. * Microsoft sells its unsuspecting users UAC as a security feature, but does NOT inform them (or at least does not inform Joe Average) that UAC is not a security boundary and they should better use a restricted^Wstandard user account instead of the administrator account created during setup. * Joe Average will happily give consent to any program which presents an UAC prompt to him: he wants to get his work done, and this UAC prompt is just an annoyance. BTW: when Windows asks him for consent, this must be right? regards Stefan Cheers, On 25 Jul 2014 00:46, Stefan Kanthak stefan.kant...@nexgo.de wrote: Brandon Perry wrote: So, I am very curious how you are finding these? Have you automated this or is it manual hand work? All my Windows installations have http://home.arcor.de/skanthak/download/SENTINEL.EXE and http://home.arcor.de/skanthak/download/SENTINEL.DLL preinstalled as C:\Program.exe and C:\Program.dll, so I'm notified when some poorly written program tries to execute them. The sentinels call MessageBox() with MB_SERVICE_NOTIFICATION, so the messages are recorded in the event log too where I can find them later. I also preinstall an APPINIT.DLL https://support.microsoft.com/kb/197571 which
