Message-ID: <CAAnPYQ49qSMd4OChL_ZYJ0dMczuvqY6bLx3Aj1CkMBwszc3n7Q@mail.gmail.com>
Date: Fri, 25 Jul 2014 18:33:36 +0200
From: Gynvael Coldwind <gynvael@...dwind.pl>
To: Stefan Kanthak <stefan.kanthak@...go.de>
Cc: fulldisclosure <fulldisclosure@...lists.org>, bugtraq@...urityfocus.com
Subject: 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.kanthak@...go.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.kanthak@...go.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 achieve this just run FORMAT C: /FS:NTFS /S:Disable in Windows PE
>>>     before you start the installation of Windows 7 and later.
>>>     For Windows NT5.x you'll have to use \i386\MIGRATE.INF
>>>
>>> > On Wed, Jul 23, 2014 at 2:50 PM, Stefan Kanthak <stefan.kanthak@...go.de
>>> >
>>> > wrote:
>>> >
>>> >> Hi @ll,
>>> >>
>>> >> the import function of Windows Mail executes a rogue program
>>> C:\Program.exe
>>> >> with the credentials of another account, resulting in a privilege
>>> >> escalation!
>>>
>>> [...]
>>>
>>> _______________________________________________
>>> Sent through the Full Disclosure mailing list
>>> http://nmap.org/mailman/listinfo/fulldisclosure
>>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>>
>>



-- 
Gynvael Coldwind

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists