"Mario Vilas" <mvilas@xxxxxxxxx> wrote: > This makes no sense. Right. "W^X" obviously doesnt make sense to YOU. > Administrator can write everywhere and users can write their own > directories. There is no privilege escalation here, no security > boundary being crossed. Who wrote anything about "privilege escalation" here? Burn your strawmen somewehre else. Stefan PS: STOP top-posting, NOW! On Thu, Aug 6, 2015 at 7:30 PM, Stefan Kanthak <stefan.kanthak@xxxxxxxx> wrote: > "Mario Vilas" <mvilas@xxxxxxxxx> wrote: > > > If it can only be written by your own user, what would be the > > security boundary being crossed here? > > Please read AGAIN what I already wrote! > > | The security boundary created by privilege separation > > ie. Administrator/root vs. "user" > > | and installation of executables in write-protected locations. > > ie. %ProgramFiles% or /usr/bin, where only privileged users can write. > > regards > Stefan > > PS: top-posting is EVIL too! > > On Wed, Aug 5, 2015 at 5:33 PM, Stefan Kanthak <stefan.kanthak@xxxxxxxx> > wrote: > > > "Mario Vilas" <mvilas@xxxxxxxxx> wrote: > > > > > %APPDATA% is within the user's home directory - by default it should > > > not be writeable by other users. > > > > Did I mention OTHER users? > > Clearly not, so your "argument" is moot. > > > > > 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. > > > > > I think "security nightmare" may be a bit of an overstatement here. > > > > No, it's just the right wording since it violates two basic principles. > > > > > I'll refrain from panicking about this "issue" for the time being. > > > > JFTR: top posting is a bad habit too! > > > > On Tue, Aug 4, 2015 at 3:22 PM, Stefan Kanthak <stefan.kanthak@xxxxxxxx> > > wrote: > > > > > Hi @ll, > > > > > > Mozilla Thunderbird 38 and newer installs and activates per default > > > the 'Lightning' extension. > > > > > > Since extensions live in the (Firefox and) Thunderbird profiles > > > (which are stored beneath %APPDATA% in Windows) and 'Lightning' comes > > > (at least for Windows) with a DLL and some Javascript, Thunderbird > > > with 'Lightning' violates one of the mandatory and basic requirements > > > of the now 20 year old "Designed for Windows" guidelines and breaks a > > > security boundary: applications must be installed in %ProgramFiles% > > > where they are protected against tampering by unprivileged users (and > > > of course malware running in their user accounts too) since only > > > privileged users can write there. > > > > > > Code installed in %APPDATA% (or any other user-writable location) is > > > but not protected against tampering. > > > This is a fundamental flaw of (not only) Mozilla's extensions, and a > > > security nightmare. > > > > > > Separation of code from (user) data also allows to use whitelisting > > > (see <https://technet.microsoft.com/en-us/library/bb457006.aspx> for > > > example) to secure Windows desktops and servers: users (and of course > > > Windows too) don't need to run code stored in their user profiles, > > > they only need to run the installed programs/applications, so unwanted > > > software including malware can easily be blocked from running. > > > > > > JFTR: current software separates code from data in virtual memory and > > > uses "write xor execute" or "data execution prevention" to > > > prevent both tampering of code and execution of data. > > > The same separation and protection can and of course needs to be > > > applied to code and data stored in the file system too! > > > > > > The Lightning extension for Windows but defeats the tamper protection > > > and code/data separation provided by Windows: > > > > > > 1. its calbasecomps.dll can be replaced or overwritten with an > > > arbitrary DLL which DllMain() is executed every time this DLL is > > > loaded; > > > > > > 2. its (XUL/chrome) Javascripts can be replaced or overwritten and > > > used to load and call arbitrary DLLs via js-ctypes. > > > > > > Only non-XUL/chrome Javascript is less critical since its execution > > > is confined by (Firefox and) Thunderbird and subject to the > > > restrictions imposed by these programs for non-XUL/chrome > Javascript. > > > > > > > > > Mitigation(s): > > > ~~~~~~~~~~~~~~ > > > > > > Disable profile local installation of extensions in Mozilla products, > > > enable ONLY application global installation of extensions. > > > > > > stay tuned > > > Stefan Kanthak > > > > > > _______________________________________________ > > > Sent through the Full Disclosure mailing list > > > https://nmap.org/mailman/listinfo/fulldisclosure > > > Web Archives & RSS: http://seclists.org/fulldisclosure/ > > > > > > > > > -- > "There's a reason we separate military and the police: one fights the enemy > of the state, the other serves and protects the people. When the military > becomes both, then the enemies of the state tend to become the people." > > -- "There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people."
