[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55C45A80.60206@jakob.io>
Date: Fri, 7 Aug 2015 09:13:04 +0200
From: Jakob Holderbaum <hi@...ob.io>
To: bugtraq@...urityfocus.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:steve@...xwiz.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.kanthak@...go.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" <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!
>
--
Jakob Holderbaum, M.Sc.
Embedded Software & Test Engineer
0176 637 297 71
http://jakob.io/
http://jakob.io/mentoring/
hi@...ob.io
@hldrbm
Powered by blists - more mailing lists