Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com wrote: W^X applies to memory protection, completely irrelevant here. I recommend to revisit elementary school and start to learn reading! http://seclists.org/bugtraq/2015/Aug/8 | 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! Plus you're saying in every situation when a user can overwrite its own binaries in its own home folder it's a bug Again: learn to read! http://seclists.org/bugtraq/2015/Aug/14 | 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. - that would make every single Linux distro vulnerable whenever you install some software in your own home directory that only you can use. # mount /home -onoexec If you're talking about file and directory permissions it makes sense to talk about privilege escalation. No. But I don't think you really understand those security principles you're citing. For example, can you give me an example of an attack scenario? The attack vector is OBVIOUS, exploitation is TRIVIAL. Also, take a chill pill. Your aggressive tone isn't really helping you at all. Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be!
RE: [FD] Mozilla extensions: a security nightmare
Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be! Here, let me fix this for you: I don't expect to be taking seriously by any technical community -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Thursday, August 06, 2015 12:33 PM To: Mario Vilas Cc: bugtraq; fulldisclosure Subject: Re: [FD] Mozilla extensions: a security nightmare Mario Vilas mvi...@gmail.com wrote: W^X applies to memory protection, completely irrelevant here. I recommend to revisit elementary school and start to learn reading! http://seclists.org/bugtraq/2015/Aug/8 | 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! Plus you're saying in every situation when a user can overwrite its own binaries in its own home folder it's a bug Again: learn to read! http://seclists.org/bugtraq/2015/Aug/14 | 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. - that would make every single Linux distro vulnerable whenever you install some software in your own home directory that only you can use. # mount /home -onoexec If you're talking about file and directory permissions it makes sense to talk about privilege escalation. No. But I don't think you really understand those security principles you're citing. For example, can you give me an example of an attack scenario? The attack vector is OBVIOUS, exploitation is TRIVIAL. Also, take a chill pill. Your aggressive tone isn't really helping you at all. Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be!
Re: [FD] Mozilla extensions: a security nightmare
I want to stress the point made here. Please continue the rather childish accusations *in private*. On 08/07/2015 08:52 AM, Frank Waarsenburg wrote: Time to unsubscribe from Bugtraq. I follow that list to be informed of vulnerabilities, not to get spammed by fighting ego's. Get a life. ___ Frank Waarsenburg Chief Information Security Officer RAM Infotechnology -Original Message- From: Steve Friedl [mailto:st...@unixwiz.net] Sent: vrijdag 7 augustus 2015 8:17 To: 'Stefan Kanthak'; 'Mario Vilas' Cc: 'bugtraq'; 'fulldisclosure' Subject: RE: [FD] Mozilla extensions: a security nightmare Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be! Here, let me fix this for you: I don't expect to be taking seriously by any technical community -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Thursday, August 06, 2015 12:33 PM To: Mario Vilas Cc: bugtraq; fulldisclosure Subject: Re: [FD] Mozilla extensions: a security nightmare Mario Vilas mvi...@gmail.com wrote: W^X applies to memory protection, completely irrelevant here. I recommend to revisit elementary school and start to learn reading! http://seclists.org/bugtraq/2015/Aug/8 | 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! Plus you're saying in every situation when a user can overwrite its own binaries in its own home folder it's a bug Again: learn to read! http://seclists.org/bugtraq/2015/Aug/14 | 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. - that would make every single Linux distro vulnerable whenever you install some software in your own home directory that only you can use. # mount /home -onoexec If you're talking about file and directory permissions it makes sense to talk about privilege escalation. No. But I don't think you really understand those security principles you're citing. For example, can you give me an example of an attack scenario? The attack vector is OBVIOUS, exploitation is TRIVIAL. Also, take a chill pill. Your aggressive tone isn't really helping you at all. Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be! -- Jakob Holderbaum, M.Sc. Embedded Software Test Engineer 0176 637 297 71 http://jakob.io/ http://jakob.io/mentoring/ h...@jakob.io @hldrbm
RE: [FD] Mozilla extensions: a security nightmare
Time to unsubscribe from Bugtraq. I follow that list to be informed of vulnerabilities, not to get spammed by fighting ego's. Get a life. ___ Frank Waarsenburg Chief Information Security Officer RAMÂ Infotechnology -Original Message- From: Steve Friedl [mailto:st...@unixwiz.net] Sent: vrijdag 7 augustus 2015 8:17 To: 'Stefan Kanthak'; 'Mario Vilas' Cc: 'bugtraq'; 'fulldisclosure' Subject: RE: [FD] Mozilla extensions: a security nightmare Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be! Here, let me fix this for you: I don't expect to be taking seriously by any technical community -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Thursday, August 06, 2015 12:33 PM To: Mario Vilas Cc: bugtraq; fulldisclosure Subject: Re: [FD] Mozilla extensions: a security nightmare Mario Vilas mvi...@gmail.com wrote: W^X applies to memory protection, completely irrelevant here. I recommend to revisit elementary school and start to learn reading! http://seclists.org/bugtraq/2015/Aug/8 | 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! Plus you're saying in every situation when a user can overwrite its own binaries in its own home folder it's a bug Again: learn to read! http://seclists.org/bugtraq/2015/Aug/14 | 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. - that would make every single Linux distro vulnerable whenever you install some software in your own home directory that only you can use. # mount /home -onoexec If you're talking about file and directory permissions it makes sense to talk about privilege escalation. No. But I don't think you really understand those security principles you're citing. For example, can you give me an example of an attack scenario? The attack vector is OBVIOUS, exploitation is TRIVIAL. Also, take a chill pill. Your aggressive tone isn't really helping you at all. Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be!
Re: [FD] Mozilla extensions: a security nightmare
Am 06.08.2015 um 21:33 schrieb Stefan Kanthak: # mount /home -o noexec bash /home/whatever/binary and you are done any attacker which don't know this would not come far at all signature.asc Description: OpenPGP digital signature
Re: [FD] Mozilla extensions: a security nightmare
Fri, Aug 7, 2015. 2:26:54 PM. Yes Please :-) Thanks cheers, /tap -Original Message- From: Jakob Holderbaum h...@jakob.io Date: Fri, 7 Aug 2015 09:13:04 To: bugtraq@securityfocus.com Subject: Re: [FD] Mozilla extensions: a security nightmare I want to stress the point made here. Please continue the rather childish accusations *in private*. On 08/07/2015 08:52 AM, Frank Waarsenburg wrote: Time to unsubscribe from Bugtraq. I follow that list to be informed of vulnerabilities, not to get spammed by fighting ego's. Get a life. ___ Frank Waarsenburg Chief Information Security Officer RAM Infotechnology -Original Message- From: Steve Friedl [mailto:st...@unixwiz.net] Sent: vrijdag 7 augustus 2015 8:17 To: 'Stefan Kanthak'; 'Mario Vilas' Cc: 'bugtraq'; 'fulldisclosure' Subject: RE: [FD] Mozilla extensions: a security nightmare Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be! Here, let me fix this for you: I don't expect to be taking seriously by any technical community -Original Message- From: Stefan Kanthak [mailto:stefan.kant...@nexgo.de] Sent: Thursday, August 06, 2015 12:33 PM To: Mario Vilas Cc: bugtraq; fulldisclosure Subject: Re: [FD] Mozilla extensions: a security nightmare Mario Vilas mvi...@gmail.com wrote: W^X applies to memory protection, completely irrelevant here. I recommend to revisit elementary school and start to learn reading! http://seclists.org/bugtraq/2015/Aug/8 | 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! Plus you're saying in every situation when a user can overwrite its own binaries in its own home folder it's a bug Again: learn to read! http://seclists.org/bugtraq/2015/Aug/14 | 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. - that would make every single Linux distro vulnerable whenever you install some software in your own home directory that only you can use. # mount /home -onoexec If you're talking about file and directory permissions it makes sense to talk about privilege escalation. No. But I don't think you really understand those security principles you're citing. For example, can you give me an example of an attack scenario? The attack vector is OBVIOUS, exploitation is TRIVIAL. Also, take a chill pill. Your aggressive tone isn't really helping you at all. Posting on top because that's where the cursor happens to be is like sh*tt*ng in your pants because that's where your *ssh*l* happens to be! -- Jakob Holderbaum, M.Sc. Embedded Software Test Engineer 0176 637 297 71 http://jakob.io/ http://jakob.io/mentoring/ h...@jakob.io @hldrbm
Re: [FD] Mozilla extensions: a security nightmare
The exact same way ubuntu and the unix os has done it for many, many years. Using the sudo method. Everytime a restricted user needs to install a plugin, they are prompted for the administrator(root) password. After reviewing windows 10, It's obvious this problem will never be fixed and people will continue to have their bank account, email and other personal passwords and information stolen. As usual, right out of the box, you are running as an administrator basically, even though windows UAC tries somewhat to emulate the unix like sudo, the user just clicks ok, because it's easy and they are not paying any attention to what is happening. If they had to type in a password and were presented with a simple do you want to install yayayhh.exe? (meta data) etc.) and an administrator password prompt, it would greatly reduce the chance of executing unwanted code. Microsoft doesn't do this because they know that people will bitch and complain. I say let them bitch and complain. Windows 10 is still pretty much an operating system for children. If you want to see how easy it is to create a botnet or obfuscate your RAT like blackshades, darkcomet eg. to easily run on windows undetected. Go check out what the folks over at hackforums are up to. Expensive cisco fw, barracuda spam filters, AV and all the encryption in the world won't do you any good if you don't understand the importance of sandboxing or worse don't understand exactly what stefan was saying, particularly when all attackers nowadays know to create a reverse connection back out through the fw to the cac server. Cheers Bruce - Original Message - From: Reindl Harald h.rei...@thelounge.net To: Stefan Kanthak stefan.kant...@nexgo.de, Ansgar Wiechers bugt...@planetcobalt.net Cc: bugtraq@securityfocus.com Sent: Thursday, August 6, 2015 5:55:05 AM Subject: Re: [FD] Mozilla extensions: a security nightmare that's all fine but * nothing new, independent of lightning * how do you imagine a restricted user install a extension otherwise * and no - he must not do that is not a acceptable solution security and usability are always a tradeoff hence the topic *is* nonsense Am 05.08.2015 um 21:27 schrieb Stefan Kanthak: Ansgar Wiechers bugt...@planetcobalt.net wrote: On 2015-08-05 Stefan Kanthak wrote: Mario Vilas mvi...@gmail.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
Re: [FD] Mozilla extensions: a security nightmare
Ansgar Wiechers bugt...@planetcobalt.net wrote: On 2015-08-05 Stefan Kanthak wrote: Mario Vilas mvi...@gmail.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
Re: [FD] Mozilla extensions: a security nightmare
that's all fine but * nothing new, independent of lightning * how do you imagine a restricted user install a extension otherwise * and no - he must not do that is not a acceptable solution security and usability are always a tradeoff hence the topic *is* nonsense Am 05.08.2015 um 21:27 schrieb Stefan Kanthak: Ansgar Wiechers bugt...@planetcobalt.net wrote: On 2015-08-05 Stefan Kanthak wrote: Mario Vilas mvi...@gmail.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 signature.asc Description: OpenPGP digital signature
Re: [FD] Mozilla extensions: a security nightmare
Reindl Harald h.rei...@thelounge.net wrote: that's all fine but * nothing new, independent of lightning ACK * how do you imagine a restricted user install a extension otherwise Real sandboxing, if not possible, give the users the possibility to activate admin-installed extension, and not the possibility to install every shit which comes with a I am free or I am sexy tag. * and no - he must not do that is not a acceptable solution Yes it is. security and usability are always a tradeoff Not always, and if, sometimes security has to win. hence the topic *is* nonsense No, it is not Just my 4 cent -- Christoph Gruber
Re: [FD] Mozilla extensions: a security nightmare
Am 06.08.2015 um 19:03 schrieb Christoph Gruber: Reindl Harald h.rei...@thelounge.net wrote: that's all fine but * nothing new, independent of lightning ACK * how do you imagine a restricted user install a extension otherwise Real sandboxing, if not possible, give the users the possibility to activate admin-installed extension, and not the possibility to install every shit which comes with a I am free or I am sexy tag. the admin-installed extensions would be installed for every user you can restrict yourself doing so by just only use packed extensions yum search mozilla | grep -i extension firefox-esteidpkcs11loader.noarch : Estonian ID card extension for Mozilla mozilla-adblockplus.noarch : Adblocking extension for Mozilla Firefox, mozilla-esteid.noarch : Estonian ID card Mozilla extension mozilla-https-everywhere.noarch : HTTPS/HSTS enforcement extension for Mozilla mozilla-noscript.noarch : JavaScript white list extension for Mozilla Firefox mozvoikko.noarch : Finnish Voikko spell-checker extension for Mozilla programs mozilla-requestpolicy.noarch : Firefox and Seamonkey extension that gives you spice-xpi.x86_64 : SPICE extension for Mozilla thunderbird-enigmail.x86_64 : Authentication and encryption extension for * and no - he must not do that is not a acceptable solution Yes it is. security and usability are always a tradeoff Not always, and if, sometimes security has to win. frankly, a lot of people hate my security-first attitude but in case of browser extensions i just don't want run to every machine for every extension update and hand out the admin-password is a no-go hence the topic *is* nonsense No, it is not well, depending on the extension (noscript) as example there are very often updates - you are in danger to train users to always and everywhere anter their root-password or skip updates which may be security relevant Mozilla is solving most of the issues by just only install signed extensions - let's wait how many people switch to the developer version without that restriction because 1 or 2 of their favorite extensions are only available directly from the developer signature.asc Description: OpenPGP digital signature
Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com 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.kant...@nexgo.de wrote: Mario Vilas mvi...@gmail.com 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.kant...@nexgo.de wrote: Mario Vilas mvi...@gmail.com 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.kant...@nexgo.de 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
Re: [FD] Mozilla extensions: a security nightmare
Well, here's my 2 cents: - Yes, it's unfortunate that firefox extensions are not in write-protected parts of the FS. - No, it's not worth eight paragraphs of ranting on this mailing list, use of all caps, or calling some piece of software evil. - The sudo-like functionality present in Windows (and OSX, most of the time. And GUIs, generally) is a hack, not a solution as such, for reasons stated below. It'll help protect you from an enemy overwriting files (well.. a bit. They could still write a Word doc, or a PDF, or some other format that can cause unfortunate things to happen), but as soon as they get any kind of execution, they're already essentially admin. - Number of google results for write xor execute: 3,550. Number of google results for nx bit: 474,000. Use the term that is more accurate, more helpful for someone researching the topic, and more common. - I'm only speaking up because this conversation has gone on for a surprising number of posts. ## Why I'm against sudo-like functionality (but not sudo) With sudo-like functionality on an O/S like Windows is that there's nothing to prevent cross-application request forgery. If I can run code on a given system, I can run administrative code on that system by creating a window that vaguely resembles the one Windows pops up asking the user to perform an update (of, for example, a firefox extension) and enter their admin password. And now I have their admin password. That's a problem in OSX, it's a problem in Windows, and it's a problem in every operating system that I've seen running a GUI. If a part of the screen were reserved for security requests, wouldn't be an issue. But it is an issue. If you care about security, and you're entering admin creds into a GUI on the system, let alone running a browser, you're Doing It Wrong(TM). With sudo, you're explicitly asking to run a program with admin creds, but more importantly you're asking to be asked for creds. You know exactly what program is asking you for the password, and you know exactly why. With Windows, who the hell knows?
Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com 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.kant...@nexgo.de wrote: Mario Vilas mvi...@gmail.com 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.kant...@nexgo.de 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.
Re: [FD] Mozilla extensions: a security nightmare
Mario Vilas mvi...@gmail.com 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.kant...@nexgo.de 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/
Re: [FD] Mozilla extensions: a security nightmare
On 2015-08-05 Stefan Kanthak wrote: Mario Vilas mvi...@gmail.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. 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. Otherwise you'd have to prevent users from putting scripts or standalone executables anywhere they have write access. Which is somewhat less than desirable (or feasible) in most environments. 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. Regards Ansgar Wiechers -- All vulnerabilities deserve a public fear period prior to patches becoming available. --Jason Coombs on Bugtraq
Mozilla extensions: a security nightmare
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
