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.reindl@xxxxxxxxxxxxx> To: "Stefan Kanthak" <stefan.kanthak@xxxxxxxx>, "Ansgar Wiechers" <bugtraq@xxxxxxxxxxxxxxxx> Cc: bugtraq@xxxxxxxxxxxxxxxxx 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" <bugtraq@xxxxxxxxxxxxxxxx> wrote: > >> On 2015-08-05 Stefan Kanthak wrote: >>> "Mario Vilas" <mvilas@xxxxxxxxx> 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
