> On 15 Jan 2015, at 13:46, Todd C. Miller wrote:
>
> We may want to add an explicit_bzero to SipHash_Final() too but
> I'll leave that up to tedu.
the siphash implementation already uses explicit_bzero, but it is in
SipHash_End. SipHash_Final is just a wrapper that byteswaps the value from
S
The bpf(4) man page's SEE ALSO section lists this as a reference:
McCanne, S. and Jacobson, V., An efficient, extensible, and
portable network monitor.
That paper is most likely an unpublished draft because it can't be found
online. The only reference I found to it is in a 1992 researc
We may want to add an explicit_bzero to SipHash_Final() too but
I'll leave that up to tedu.
- todd
Index: lib/libc/hash/helper.c
===
RCS file: /cvs/src/lib/libc/hash/helper.c,v
retrieving revision 1.11
diff -u -r1.11 helper.c
--- li
libpcap has a use after free (found via LLVM).
pcap_close() currently looks like this:
void
pcap_close(pcap_t *p)
{
if (p->opt.source != NULL)
free(p->opt.source);
pcap_cleanup_bpf(p);
free(p);
}
The bug affects libpcap programs that enable monitor mode on
> Am 15.01.2015 um 02:51 schrieb Jonathan Gray :
>
> The '_all' PSR mask ends up being treated as 'fc' so switch 'msr'
> instructions with '_all' to '_fsxc' so bits 23-8 are restored.
> In older arm cores these bits were reserved now they are used.
>
> While here fix 'mrs' instructions to not u
The following Bitrig commit seems to be required for
the Compulab Utilite and doesn't cause any problems on bbb.
commit 6ea8cdd3daffb2edde3eadf87d3fea6d2f47384c
Author: Patrick Wildt
The '_all' PSR mask ends up being treated as 'fc' so switch 'msr'
instructions with '_all' to '_fsxc' so bits 23-8 are restored.
In older arm cores these bits were reserved now they are used.
While here fix 'mrs' instructions to not use psr masks, they
should take psr names. In other words 'spsr
On 14Jan2015 18:18, Theo de Raadt wrote:
On 14Jan2015 01:05, Theo de Raadt wrote:
>> On Tue, Jan 13, 2015 at 11:38:49PM -0800, Philip Guenther wrote:
>> > On Tue, Jan 13, 2015 at 11:36 PM, Philip Guenther
wrote:
>> > > On Tue, Jan 13, 2015 at 11:38 PM, Mike Larkin
wrote:
>> > >> i386 is nex
On 14Jan2015 01:05, Theo de Raadt wrote:
On Tue, Jan 13, 2015 at 11:38:49PM -0800, Philip Guenther wrote:
> On Tue, Jan 13, 2015 at 11:36 PM, Philip Guenther wrote:
> > On Tue, Jan 13, 2015 at 11:38 PM, Mike Larkin wrote:
> >> i386 is next, but that requires a PAE paging model and compatible C
> On 14Jan2015 01:05, Theo de Raadt wrote:
> >> On Tue, Jan 13, 2015 at 11:38:49PM -0800, Philip Guenther wrote:
> >> > On Tue, Jan 13, 2015 at 11:36 PM, Philip Guenther
> >> > wrote:
> >> > > On Tue, Jan 13, 2015 at 11:38 PM, Mike Larkin
> >> > > wrote:
> >> > >> i386 is next, but that requir
On Wed, Jan 14, 2015 at 5:52 PM, Theo de Raadt
wrote:
>> > By the time an attacker has the control to search down, he surely
>> > already is capable of doing something other things. "Searching"
>> > almost certainly implies he is executing or ROP'ing.
>>
>> This is perhaps just me coming from the
On Wed, Jan 14, 2015 at 15:44, Mathias Svensson wrote:
>
> - The ps_struct structure is placed at a known address and contains
> pointers to the stack.
> - The entire region from the stack to USRSTACK is mapped, meaning that
> an attacker with the capability to repeatedly leak from a chosen
> addr
> > By the time an attacker has the control to search down, he surely
> > already is capable of doing something other things. "Searching"
> > almost certainly implies he is executing or ROP'ing.
>
> This is perhaps just me coming from the security CTF community where
> binaries are a bit contrive
On Wed, Jan 14, 2015 at 4:51 PM, Theo de Raadt
wrote:
>> There multiple issues with the way randomization of the stack is
>> done on OpenBSD 5.6, most of which I think could be fixed without
>> significant trouble.
>
> This could be improved, because a sysctl is used to find the ps info
> block.
> On Wed, Jan 14, 2015 at 3:44 PM, Mathias Svensson wrote:
> > Calls to malloc or mmap seems to be chosen randomly among 2 ** 20
> > pages placed at a constant offset above the base of the binary.
> > While none of these numbers are great (25 bits to base address with
> > no knowledge, 20 bits if k
On Wed, Jan 14, 2015 at 3:44 PM, Mathias Svensson wrote:
> Calls to malloc or mmap seems to be chosen randomly among 2 ** 20
> pages placed at a constant offset above the base of the binary.
> While none of these numbers are great (25 bits to base address with
> no knowledge, 20 bits if knowing ano
> There multiple issues with the way randomization of the stack is done
> on OpenBSD 5.6, most of which I think could be fixed without
> significant trouble.
This could be improved, because a sysctl is used to find the ps info block.
It is currently same for all processes. It could be made differ
On Fri, 09 Jan 2015 08:57:28 -0700, "Todd C. Miller" wrote:
> I've tabled the other strlcpy/strlcat version because it
> required that the strings be traversed twice.
>
> However, these files were originally written with register variables
> and can be simplified slightly now that we let the comp
Hello,
I am sorry if this is the wrong mailing list to send to. I was
directed here by __gilles on #opensmtpd @ Freenode.
There multiple issues with the way randomization of the stack is done
on OpenBSD 5.6, most of which I think could be fixed without
significant trouble.
It seems like the issu
There are some assumptions in spamd-setup that are likely to be
false.
1) If you have a large number of IP addresses without a netmask
(common) then the assumption of one IP for every 16 bytes in
black/whitelist files will be wrong. One IP for every 14 bytes
seems closer in practice.
2)
> On Tue, Jan 13, 2015 at 11:38:49PM -0800, Philip Guenther wrote:
> > On Tue, Jan 13, 2015 at 11:36 PM, Philip Guenther
> > wrote:
> > > On Tue, Jan 13, 2015 at 11:38 PM, Mike Larkin
> > > wrote:
> > >> i386 is next, but that requires a PAE paging model and compatible CPU.
> > >> I've got the
On Tue, Jan 13, 2015 at 11:38:49PM -0800, Philip Guenther wrote:
> On Tue, Jan 13, 2015 at 11:36 PM, Philip Guenther wrote:
> > On Tue, Jan 13, 2015 at 11:38 PM, Mike Larkin wrote:
> >> i386 is next, but that requires a PAE paging model and compatible CPU.
> >> I've got the PAE mode booting but i
22 matches
Mail list logo
