[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <FCC5E10A7212452D84505CFFAF7D9C5B@W340>
Date: Thu, 6 Aug 2015 21:33:00 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: "Mario Vilas" <mvilas@...il.com>
Cc: "bugtraq" <bugtraq@...urityfocus.com>,
"fulldisclosure" <fulldisclosure@...lists.org>
Subject: Re: [FD] Mozilla extensions: a security nightmare
"Mario Vilas" <mvilas@...il.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!
Powered by blists - more mailing lists