On Sat, Jan 3, 2015 at 3:19 PM, Richard Weinberger wrote:
> Am 04.01.2015 um 00:06 schrieb Andy Lutomirski:
>> As an attempt to help end this particular line of debate: putting the
>> sleep in glibc won't work. The point isn't to make the crashed
>> process crash more slowly; it's to limit the
On Sat, Jan 3, 2015 at 3:19 PM, Richard Weinberger rich...@nod.at wrote:
Am 04.01.2015 um 00:06 schrieb Andy Lutomirski:
As an attempt to help end this particular line of debate: putting the
sleep in glibc won't work. The point isn't to make the crashed
process crash more slowly; it's to
Am 04.01.2015 um 00:06 schrieb Andy Lutomirski:
> As an attempt to help end this particular line of debate: putting the
> sleep in glibc won't work. The point isn't to make the crashed
> process crash more slowly; it's to limit the rate at which *new*
> siblings can be forked and crashed as a
Am 04.01.2015 um 00:01 schrieb Pavel Machek:
> On Sat 2015-01-03 23:44:18, Richard Weinberger wrote:
>> Am 03.01.2015 um 23:36 schrieb Pavel Machek:
>>>
>> No. This is not what this patch does.
>>
>>> But changing glibc to do sleep(30); abort(); instead of abort(); to
>>> slow down
On Sat, Jan 3, 2015 at 2:36 PM, Pavel Machek wrote:
>
>> >> No. This is not what this patch does.
>> >>
>> >>> But changing glibc to do sleep(30); abort(); instead of abort(); to
>> >>> slow down bruteforcing of canaries makes some kind of sense... and
>> >>> should be ok by default.
>> >>
>> >>
On Sat 2015-01-03 23:44:18, Richard Weinberger wrote:
> Am 03.01.2015 um 23:36 schrieb Pavel Machek:
> >
> No. This is not what this patch does.
>
> > But changing glibc to do sleep(30); abort(); instead of abort(); to
> > slow down bruteforcing of canaries makes some kind of
Am 03.01.2015 um 23:36 schrieb Pavel Machek:
>
No. This is not what this patch does.
> But changing glibc to do sleep(30); abort(); instead of abort(); to
> slow down bruteforcing of canaries makes some kind of sense... and
> should be ok by default.
As I saidn
> >> No. This is not what this patch does.
> >>
> >>> But changing glibc to do sleep(30); abort(); instead of abort(); to
> >>> slow down bruteforcing of canaries makes some kind of sense... and
> >>> should be ok by default.
> >>
> >> As I saidn only focusing one the specific stack canary case
Am 03.01.2015 um 00:08 schrieb Pavel Machek:
> On Sat 2015-01-03 00:00:22, Richard Weinberger wrote:
>> Am 02.01.2015 um 23:54 schrieb Pavel Machek:
>>> On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
On Fri, 2 Jan 2015, Pavel Machek wrote:
>> You also want to protect against binaries
Am 03.01.2015 um 00:08 schrieb Pavel Machek:
On Sat 2015-01-03 00:00:22, Richard Weinberger wrote:
Am 02.01.2015 um 23:54 schrieb Pavel Machek:
On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
On Fri, 2 Jan 2015, Pavel Machek wrote:
You also want to protect against binaries that are evil on
No. This is not what this patch does.
But changing glibc to do sleep(30); abort(); instead of abort(); to
slow down bruteforcing of canaries makes some kind of sense... and
should be ok by default.
As I saidn only focusing one the specific stack canary case is not enough.
Ok,
Am 04.01.2015 um 00:01 schrieb Pavel Machek:
On Sat 2015-01-03 23:44:18, Richard Weinberger wrote:
Am 03.01.2015 um 23:36 schrieb Pavel Machek:
No. This is not what this patch does.
But changing glibc to do sleep(30); abort(); instead of abort(); to
slow down bruteforcing of canaries makes
On Sat 2015-01-03 23:44:18, Richard Weinberger wrote:
Am 03.01.2015 um 23:36 schrieb Pavel Machek:
No. This is not what this patch does.
But changing glibc to do sleep(30); abort(); instead of abort(); to
slow down bruteforcing of canaries makes some kind of sense... and
should be ok
On Sat, Jan 3, 2015 at 2:36 PM, Pavel Machek pa...@ucw.cz wrote:
No. This is not what this patch does.
But changing glibc to do sleep(30); abort(); instead of abort(); to
slow down bruteforcing of canaries makes some kind of sense... and
should be ok by default.
As I saidn only
Am 03.01.2015 um 23:36 schrieb Pavel Machek:
No. This is not what this patch does.
But changing glibc to do sleep(30); abort(); instead of abort(); to
slow down bruteforcing of canaries makes some kind of sense... and
should be ok by default.
As I saidn only focusing one the specific
Am 04.01.2015 um 00:06 schrieb Andy Lutomirski:
As an attempt to help end this particular line of debate: putting the
sleep in glibc won't work. The point isn't to make the crashed
process crash more slowly; it's to limit the rate at which *new*
siblings can be forked and crashed as a canary
On Sat 2015-01-03 00:00:22, Richard Weinberger wrote:
> Am 02.01.2015 um 23:54 schrieb Pavel Machek:
> > On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
> >> On Fri, 2 Jan 2015, Pavel Machek wrote:
> >>
> You also want to protect against binaries that are evil on purpose,
> right?
> >>>
>
Am 02.01.2015 um 23:54 schrieb Pavel Machek:
> On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
>> On Fri, 2 Jan 2015, Pavel Machek wrote:
>>
You also want to protect against binaries that are evil on purpose,
right?
>>>
>>> Umm. No. Not by default. We don't want to break crashme or
On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
> On Fri, 2 Jan 2015, Pavel Machek wrote:
>
> > > You also want to protect against binaries that are evil on purpose,
> > > right?
> >
> > Umm. No. Not by default. We don't want to break crashme or trinity by
> > default.
>
> I thought trinity is
On Fri, 2 Jan 2015, Jiri Kosina wrote:
> > > You also want to protect against binaries that are evil on purpose,
> > > right?
> >
> > Umm. No. Not by default. We don't want to break crashme or trinity by
> > default.
>
> I thought trinity is issuing syscalls directly (would make more sense than
On Fri, 2 Jan 2015, Pavel Machek wrote:
> > You also want to protect against binaries that are evil on purpose,
> > right?
>
> Umm. No. Not by default. We don't want to break crashme or trinity by
> default.
I thought trinity is issuing syscalls directly (would make more sense than
going
On Fri 2015-01-02 23:32:35, Jiri Kosina wrote:
> On Fri, 2 Jan 2015, Pavel Machek wrote:
>
> > > > Can the slowdown be impelmented in glibc, then?
> > >
> > > glibc has a lot of asserts where it can detect stack smashing and kills
> > > the
> > > current process using abort(). Here it could of
On Fri, 2 Jan 2015, Pavel Machek wrote:
> > > Can the slowdown be impelmented in glibc, then?
> >
> > glibc has a lot of asserts where it can detect stack smashing and kills the
> > current process using abort(). Here it could of course also call
> > sleep().
>
> Please do it in glibc, then.
On Fri 2015-01-02 22:40:14, Richard Weinberger wrote:
> Am 02.01.2015 um 20:46 schrieb Pavel Machek:
> >>> Does this break trinity, crashme, and similar programs?
> >>
> >> If they fork() without execve() and a child dies very fast the next fork()
> >> will be throttled.
> >> This is why I'd like
Am 02.01.2015 um 20:46 schrieb Pavel Machek:
>>> Does this break trinity, crashme, and similar programs?
>>
>> If they fork() without execve() and a child dies very fast the next fork()
>> will be throttled.
>> This is why I'd like to make this feature disabled by default.
>>
>>> Can you detect it
On Fri 2015-01-02 12:00:08, Richard Weinberger wrote:
> Am 02.01.2015 um 06:11 schrieb Pavel Machek:
> > On Tue 2014-12-30 10:40:15, Kees Cook wrote:
> >> On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger wrote:
> >>> While exploring the offset2lib attack I remembered that
> >>> grsecurity has
Am 02.01.2015 um 06:11 schrieb Pavel Machek:
> On Tue 2014-12-30 10:40:15, Kees Cook wrote:
>> On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger wrote:
>>> While exploring the offset2lib attack I remembered that
>>> grsecurity has an interesting feature to make such attacks
>>> much harder.
Am 02.01.2015 um 06:11 schrieb Pavel Machek:
On Tue 2014-12-30 10:40:15, Kees Cook wrote:
On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger rich...@nod.at wrote:
While exploring the offset2lib attack I remembered that
grsecurity has an interesting feature to make such attacks
much harder.
On Fri 2015-01-02 12:00:08, Richard Weinberger wrote:
Am 02.01.2015 um 06:11 schrieb Pavel Machek:
On Tue 2014-12-30 10:40:15, Kees Cook wrote:
On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger rich...@nod.at wrote:
While exploring the offset2lib attack I remembered that
grsecurity has
On Fri 2015-01-02 22:40:14, Richard Weinberger wrote:
Am 02.01.2015 um 20:46 schrieb Pavel Machek:
Does this break trinity, crashme, and similar programs?
If they fork() without execve() and a child dies very fast the next fork()
will be throttled.
This is why I'd like to make this
On Fri 2015-01-02 23:32:35, Jiri Kosina wrote:
On Fri, 2 Jan 2015, Pavel Machek wrote:
Can the slowdown be impelmented in glibc, then?
glibc has a lot of asserts where it can detect stack smashing and kills
the
current process using abort(). Here it could of course also call
On Fri, 2 Jan 2015, Pavel Machek wrote:
Can the slowdown be impelmented in glibc, then?
glibc has a lot of asserts where it can detect stack smashing and kills the
current process using abort(). Here it could of course also call
sleep().
Please do it in glibc, then.
You also want
On Sat 2015-01-03 00:00:22, Richard Weinberger wrote:
Am 02.01.2015 um 23:54 schrieb Pavel Machek:
On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
On Fri, 2 Jan 2015, Pavel Machek wrote:
You also want to protect against binaries that are evil on purpose,
right?
Umm. No. Not by
Am 02.01.2015 um 23:54 schrieb Pavel Machek:
On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
On Fri, 2 Jan 2015, Pavel Machek wrote:
You also want to protect against binaries that are evil on purpose,
right?
Umm. No. Not by default. We don't want to break crashme or trinity by
default.
I
On Fri 2015-01-02 23:49:52, Jiri Kosina wrote:
On Fri, 2 Jan 2015, Pavel Machek wrote:
You also want to protect against binaries that are evil on purpose,
right?
Umm. No. Not by default. We don't want to break crashme or trinity by
default.
I thought trinity is issuing syscalls
On Fri, 2 Jan 2015, Jiri Kosina wrote:
You also want to protect against binaries that are evil on purpose,
right?
Umm. No. Not by default. We don't want to break crashme or trinity by
default.
I thought trinity is issuing syscalls directly (would make more sense than
going
On Fri, 2 Jan 2015, Pavel Machek wrote:
You also want to protect against binaries that are evil on purpose,
right?
Umm. No. Not by default. We don't want to break crashme or trinity by
default.
I thought trinity is issuing syscalls directly (would make more sense than
going through
Am 02.01.2015 um 20:46 schrieb Pavel Machek:
Does this break trinity, crashme, and similar programs?
If they fork() without execve() and a child dies very fast the next fork()
will be throttled.
This is why I'd like to make this feature disabled by default.
Can you detect it died due to the
On Tue 2014-12-30 10:40:15, Kees Cook wrote:
> On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger wrote:
> > While exploring the offset2lib attack I remembered that
> > grsecurity has an interesting feature to make such attacks
> > much harder. Exploits can brute stack canaries often very easily
On Tue 2014-12-30 10:40:15, Kees Cook wrote:
On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger rich...@nod.at wrote:
While exploring the offset2lib attack I remembered that
grsecurity has an interesting feature to make such attacks
much harder. Exploits can brute stack canaries often very
Am 30.12.2014 um 19:40 schrieb Kees Cook:
> On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger wrote:
>> While exploring the offset2lib attack I remembered that
>> grsecurity has an interesting feature to make such attacks
>> much harder. Exploits can brute stack canaries often very easily
>> if
On Tue, Dec 30, 2014 at 10:40 AM, Kees Cook wrote:
> On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger wrote:
>> While exploring the offset2lib attack I remembered that
>> grsecurity has an interesting feature to make such attacks
>> much harder. Exploits can brute stack canaries often very
On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger wrote:
> While exploring the offset2lib attack I remembered that
> grsecurity has an interesting feature to make such attacks
> much harder. Exploits can brute stack canaries often very easily
> if the target is a forking server like sshd or
On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger rich...@nod.at wrote:
While exploring the offset2lib attack I remembered that
grsecurity has an interesting feature to make such attacks
much harder. Exploits can brute stack canaries often very easily
if the target is a forking server like
On Tue, Dec 30, 2014 at 10:40 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger rich...@nod.at wrote:
While exploring the offset2lib attack I remembered that
grsecurity has an interesting feature to make such attacks
much harder. Exploits can brute
Am 30.12.2014 um 19:40 schrieb Kees Cook:
On Wed, Dec 24, 2014 at 1:39 PM, Richard Weinberger rich...@nod.at wrote:
While exploring the offset2lib attack I remembered that
grsecurity has an interesting feature to make such attacks
much harder. Exploits can brute stack canaries often very
While exploring the offset2lib attack I remembered that
grsecurity has an interesting feature to make such attacks
much harder. Exploits can brute stack canaries often very easily
if the target is a forking server like sshd or Apache httpd.
The problem is that after fork() the child has by
While exploring the offset2lib attack I remembered that
grsecurity has an interesting feature to make such attacks
much harder. Exploits can brute stack canaries often very easily
if the target is a forking server like sshd or Apache httpd.
The problem is that after fork() the child has by
48 matches
Mail list logo
