Date: Thu, 8 Oct 2015 12:21:59 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <syberghost@...il.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] WinRAR SFX v5.21 - Remote Code Execution Vulnerability

"Shawn McMahon" syberghost@...il.com wrote:

> On Mon, Oct 5, 2015 at 8:16 AM, Stefan Kanthak <stefan.kanthak@...go.de>
> wrote:
> 
>>
>> That's why giving unsuspecting users *.EXE to install a software package
>> or to unpack an archive and thus training them to run almost anything
>> they get their hands on is a BLOODY STUPID idea in the first place.
>>
>> ALWAYS use the platforms native package or archive formats to distribute
>> your software or files!
>>
> 
> Perhaps it's my ignorance talking, but I just don't see how:
> 
> "Run this EXE that might contain bad stuff" is worse than:
> 
> "Install this .msi as Admin that might contain bad stuff" or "install this
> RPM as root that might contain bad stuff" or "install this .pkg as root
> that might contain bad stuff."

1. installation <> execution;
2. installation of a package does NOT require administrative rights in
   general!

> The vulnerability is installing things when you don't know what they are or
> where they came from, not the particular form in which they're packaged.

No!
The point is: well-known package formats allow you to inspect "things",
EXE generally dont.
In more detail:

1. It's not a vulnerability, but a weakness and (design) bug in the first
   place: there is no need to EXEcute programs from (possibly) untrusted
   sources or with questionable (unknown) contents to install software.

   This weakness turns into a vulnerability:
   - if Jane or Joe Average execute arbitrary (untrusted) EXEcutables
   - if a trusted EXEcutable loads and/or executes a rogue DLL or EXE
     which just happen to be in the search path before the expected DLL
     or EXE (known as DLL hijacking/preloading/sideloading or binary
     planting).

2. EXE are generally opaque: you cant tell what they REALLY do unless you
   have their source (and built them yourself).
   In case of installers, you need the source of the installer/unpacker,
   the source of the creator and the source of the script used to build
   the final EXE.
   
   Some installers allow to unpack their payload, but you have to EXEcute
   them for this purpose too (so this option gains nothing).
   In many cases the "primary" EXE is just an unpacker, and its payload
   is the real installer ... which puts you back at the start.

   Some unpackers allow to display the instructions they execute to run
   the payload.
   ALMOST ALL installers provide no means to display these instructions.

3. All current operating systems have a package installer of their own.
   This package installer is trusted.
   It does not EXEcute the packages it installs, but reads them as data
   and interprets them, i.e. executes their instructions (yes, these can
   include "execute one of the files of the package", but read on).
   And it need not be run with administrative privileges at all.
   You can even use it in locked-down environments where users dont
   have the rights/permissions to execute arbitrary files/programs, but
   may use only white-listed applications/programs (which renders
   instructions to execute something contained in the package useless).

   The format of these packages is well-known and documented, they can
   be unpacked and their contents as well as their instructions read
   and inspected.
   The tools to create/build, edit/modify, unpack and even rebuild them
   are typically part of the OS's package manager or provided as part of
   the OS's software development kit.

> If it's got a GUI, clicking on its packages is going to prompt you to
> escalate privileges and install them.

Some OS behave this way. Others can be configured to behave better.
Let's stick with Windows:

1. installation of *.MSI and *.MSP is subject to software restriction
   policies a.k.a. SAFER as well as AppLocker.

JFTR: "protected" administrators are subject to these policies, and the
      policies can be enforced even for elevated administrators.

2. elevation (and the UAC prompt) can be disabled for users in "standard"
   user accounts.

3. users in "standard" user accounts need an administrator password to
   answer the UAC prompt and elevate the privileges.

> If I'm missing something, drop some knowledge on me and I'll install it.
> Even if it's not signed. :)

You already wrote that you are ignorant.-P

stay tuned
Stefan

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

Powered by blists - more mailing lists