[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AEB6C3B591FF4CF6AEF8A8F5B42B92DA@W340>
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