lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Aug 2015 21:27:42 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: "Ansgar Wiechers" <bugtraq@...netcobalt.net>
Cc: <bugtraq@...urityfocus.com>
Subject: Re: [FD] Mozilla extensions: a security nightmare

"Ansgar Wiechers" <bugtraq@...netcobalt.net> wrote:

> On 2015-08-05 Stefan Kanthak wrote:
>> "Mario Vilas" <mvilas@...il.com> wrote:
>>> If this is the case then the problem is one of bad file permissions,
>>> not the location.
>>>
>>> Incidentally, many other browsers and tons of software also store
>>> executable code in %APPDATA%.
>> 
>> Cf. <http://seclists.org/fulldisclosure/2013/Aug/198>
>> 
>> EVERY program which stores executable code in user-writable locations
>> is CRAPWARE and EVIL since it undermines the security boundary created
>> by privilege separation and installation of executables in
>> write-protected locations.
>> Both are BASIC principles of computer security.
> 
> Nonsense.

Really?

> That only becomes an issue if anyone other than the user putting the
> code into the location is supposed to be running something from that
> location.

Are you SURE that everybody who installs TB 38 knows or recognizes
that TB writes executable code to their user profile(s)?
Who is but the user who puts the code into that location in the first
place?
The user who executes TB and let it create/update the profile?
The administrator who installs TB?
The creator of TBs installer?
 
> Otherwise you'd have to prevent users from putting scripts or
> standalone executables anywhere they have write access.

No. Writing executable code is NOT the problem here.
The problem is running this code AFTER it has been tampered.
(Not only) Mozilla but does NOT detect tampered code.

> Which is somewhat less than desirable (or feasible) in most environments.

I recommend to get the idea of "write Xor execute"...

> The problem with browser extensions is that they're exposed to input
> from the outside world, which could make them remotely exploitable in
> case of a vulnerability, and that user-installed extensions are not
> subject to company software update procedures.

That's still ANOTHER problem.

regards
Stefan

Powered by blists - more mailing lists