[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FD] WinRAR SFX v5.21 - Remote Code Execution Vulnerability
- To: <syberghost@xxxxxxxxx>
- Subject: Re: [FD] WinRAR SFX v5.21 - Remote Code Execution Vulnerability
- From: "Stefan Kanthak" <stefan.kanthak@xxxxxxxx>
- Date: Thu, 8 Oct 2015 12:21:59 +0200
"Shawn McMahon" syberghost@xxxxxxxxx wrote:
> On Mon, Oct 5, 2015 at 8:16 AM, Stefan Kanthak <stefan.kanthak@xxxxxxxx>
> 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/