On Sun, Nov 24, 2013 at 3:53 AM, Darius Jahandarie wrote:
> Although Debian *developers* can't find and fix all upstream bugs, the
> Debian project, as the funnel between code and users, provides an
> interesting location to perform this sort of automated static analysis
> on all source code flowi
Stefan Roas (2013-11-23):
> On Sat Nov 23, 2013 at 10:18:43, Robert Baron wrote:
> > Second question:
> >
> > Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't
> > this why memcpy is preferred over strcpy?
>
> Nope. There's memmove for overlapping areas.
Indeed, easy enou
On Sun, Nov 24, 2013 at 12:18 AM, Robert Baron
wrote:
> Second question:
>
> Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't
> this why memcpy is preferred over strcpy?
>[...]
The reason memcpy() is preferred over strcpy() is the same as the
reason strncpy() is preferred
[Not sure this really needs to be cc-ed to security@]
On Sun, Nov 24, 2013 at 12:09 AM, Robert Baron
wrote:
> Aren't many of the constructs used as examples in the paper are commonly
> used in c programming. For example it is very common to see a function that
> has a pointer as a parameter def
On Sat, Nov 23, 2013 at 4:52 PM, Jann Horn wrote:
> On Sat, Nov 23, 2013 at 08:14:34AM -0500, Brad Alexander wrote:
>> Any program at a level not very much above Hello World
>> in the language of your choice is likely to have bugs.
>
> Isn't that a bit extreme? I think that a good programmer who se
On Sat, Nov 23, 2013 at 08:14:34AM -0500, Brad Alexander wrote:
> Any program at a level not very much above Hello World
> in the language of your choice is likely to have bugs.
Isn't that a bit extreme? I think that a good programmer who seriously
tries to code carefully should be able to impleme
On Sat, Nov 23, 2013 at 1:16 PM, Mark Haase wrote:
> Anyway, I don't see what this has to do with Debian. It's an interesting
> paper, but Debian can't find and fix all upstream bugs, nor do I think most
> users would be happy if suddenly everything was compiled without any
> optimizations.
Altho
The researchers' point was that an attacker might be able to remap that memory
page so that dereferencing a null pointer would NOT segfault. (I don't actually
know how feasible this is; I'm just paraphrasing their argument. They footnote
this claim but I didn't bother to read the cited sources.)
On Sun, Nov 17, 2013 at 10:42 AM, Michael Gilbert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> - -
> Debian Security Advisory DSA-2797-1 secur...@debian.org
> http://www.debian.org/security/
[...]
> Isn't it interesting that their one example will potentially dereference
> the null pointer even before compiler optimizations (from the paper):
>
> struct tun_struct *tun=;
> struct sock *sk = tun->sk;
> if(*tun) return POLLERR;
>
> The check to see that tun is non-null should occur
On Sat Nov 23, 2013 at 10:18:43, Robert Baron wrote:
> Second question:
>
> Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't
> this why memcpy is preferred over strcpy?
Nope. There's memmove for overlapping areas.
--
To UNSUBSCRIBE, email to debian-security-requ...@list
Second question:
Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't
this why memcpy is preferred over strcpy?
On Sat, Nov 23, 2013 at 10:09 AM, Robert Baron <
robertbartlettba...@gmail.com> wrote:
> Aren't many of the constructs used as examples in the paper are commonly
Aren't many of the constructs used as examples in the paper are commonly
used in c programming. For example it is very common to see a function
that has a pointer as a parameter defined as:
int func(void *ptr)
{
if(!ptr) return SOME_ERROR;
/* rest of function*/
return 1;
}
I
Deja gnu?
On Sat, Nov 23, 2013 at 10:34 AM, Andrew McGlashan
wrote:
> Hi,
>
> The following link shows the issue in a nutshell:
>
> http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c
>
> [it refers to the PDF that I mentioned]
>
> --
> Kind Regards
On Sat, Nov 23, 2013 at 6:18 AM, Michael Tautschnig wrote:
>
> >
> > This looks very serious indeed, but a quick search of Debian mailing
> > lists didn't show anything being acknowledged for this issue should
> > Debian users be concerned?
> >
>
> Probably not more than before, but as much a
Hi Andrew, hi all,
> I understand that Debian has a bunch of vulnerabilities as described in
> the following PDF.
>
> http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
>
> Just a small quote:
>
> "This paper presents the first systematic approach for
> reasoning about and detecting unstable
16 matches
Mail list logo
