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 ra
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 cana
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.
>> >>
>> >> A
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 sen
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
> >> 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
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
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 trinity
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 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 throug
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 c
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.
Yo
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 t
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 a
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. Expl
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
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 eas
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 Apac
23 matches
Mail list logo
