On 11/28/2013 03:28 AM, Joel Rees wrote:
> And, according to the article that started this thread, isn't going to
> do the job, either, since many of our primary compilers now optimize
> more than they are able to warn about even at the lowest level of
> optimization.
This should be enough to thro
On 28/11/13 22:33, Joel Rees wrote:
>> [...]
>
> Uninitialized pointers in my thought processes.
>
Made perfect sense to me.
I use ld.so.preload for everything. It's great.
Kind regards
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
Ick.
On Thu, Nov 28, 2013 at 8:28 PM, Joel Rees wrote:
> On Thu, Nov 28, 2013 at 6:10 AM, Wade Richards wrote:
>> [...]
> I'm taking a course in embedded programming at the local employment
> training center to "brush up" on skills I never lost, for reasons that
> I won't bother to explain. The
On Thu, Nov 28, 2013 at 6:10 AM, Wade Richards wrote:
> One of the links Mark posted earlier addresses the "The compiler should
> issue warnings" issue. The short answer is because of macro expansion and
> other code-rearranging optimizations (inlining functions, loop unrolling,
> pulling express
On 27/11/13 13:10, Wade Richards wrote:
Also, the deeper you get into the optimized code, the harder it is to
issue meaningful source-level warnings. E.g. when the compiler optimizes:
static int decimate(x) { return x/10; }
int foo() {
int a=INT_MAX;
int b;
for(i=0; i<100; ++i) { b=max
One of the links Mark posted earlier addresses the "The compiler should issue
warnings" issue. The short answer is because of macro expansion and other
code-rearranging optimizations (inlining functions, loop unrolling, pulling
expressions out of a loop, etc.), undefined code appears and is rem
On 26/11/13 11:37, Mark Haase wrote:
Compiler developers, for better or worse, reserve the right to do
whatever they want with undefined behavior, and it's up to the person
writing the C code to not include undefined behavior in their own program.
That's a fallacy. The fact that a compiler does
On 13Nov27:2356+1100, Scott Ferguson wrote:
> On 27/11/13 23:37, David L. Craig wrote:
> > On 13Nov27:1423+1100, Scott Ferguson wrote:
> >
> >> On 27/11/13 13:49, David L. Craig wrote:
> >
> >>> On 13Nov26:1545-0500, David L. Craig wrote:
> >>>
> On 13Nov26:1437-0500, Mark Haase wrote:
> >>>
On 27/11/13 23:37, David L. Craig wrote:
> On 13Nov27:1423+1100, Scott Ferguson wrote:
>
>> On 27/11/13 13:49, David L. Craig wrote:
>
>>> On 13Nov26:1545-0500, David L. Craig wrote:
>>>
On 13Nov26:1437-0500, Mark Haase wrote:
> Therefore, a Linux distribution has 2 choices: (1) wai
On 13Nov27:1423+1100, Scott Ferguson wrote:
> On 27/11/13 13:49, David L. Craig wrote:
> > On 13Nov26:1545-0500, David L. Craig wrote:
> >
> >> On 13Nov26:1437-0500, Mark Haase wrote:
> >>
> >>> Therefore, a Linux distribution has 2 choices: (1) wait for upstream
> >>> patches for bugs/vulnerabi
On 27/11/13 13:49, David L. Craig wrote:
> On 13Nov26:1545-0500, David L. Craig wrote:
>
>> On 13Nov26:1437-0500, Mark Haase wrote:
>>
>>> Therefore, a Linux distribution has 2 choices: (1) wait for upstream
>>> patches for bugs/vulnerabilities as they are found, or (2) recompile all
>>> packages
On 13Nov26:1545-0500, David L. Craig wrote:
> On 13Nov26:1437-0500, Mark Haase wrote:
>
> > Therefore, a Linux distribution has 2 choices: (1) wait for upstream
> > patches for bugs/vulnerabilities as they are found, or (2) recompile all
> > packages with optimizations disabled. I don't think pro
* Bob Proulx:
> In those systems the zero page is initially bit-zero and reading from
> the zero point will return zero values from the contents there. If
> the program writes to the zero page then subsequent reads will return
> whatever was written there. This is bad behavior that was the defau
On 13Nov26:1437-0500, Mark Haase wrote:
> Therefore, a Linux distribution has 2 choices: (1) wait for upstream
> patches for bugs/vulnerabilities as they are found, or (2) recompile all
> packages with optimizations disabled. I don't think proposal #2 would get
> very far...
Well, there's always
Wow... that really is kind of testy. And... point taken.
Mark Haase wrote:
Miles, the GCC developers don't consider this to be a bug, and so I
doubt that any of it will be "fixed". For example, here is a "bug"
cited in the paper:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
If you have
Miles, the GCC developers don't consider this to be a bug, and so I doubt
that any of it will be "fixed". For example, here is a "bug" cited in the
paper:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
If you have a moment, read through that thread. It gets pretty testy as the
developers argue
Going back through the discussion on this thread, I'm taken by two main
reactions:
- discussion of the specific class of bugs/security holes
- a lot of comments that "this is an issue for upstream"
What I haven't seen, so I'll add it to the discussion, is that this
strikes me as an issue for "
On Mon, Nov 25, 2013 at 03:10:07PM -0700, Bob Proulx wrote:
In those systems the zero page is initially bit-zero and reading from
the zero point will return zero values from the contents there. If
the program writes to the zero page then subsequent reads will return
whatever was written there.
Robert Baron wrote:
> struct tun_struct *tun=;
> struct sock *sk = tun->sk;
> if(*tun) return POLLERR;
>
> The check to see that tun is non-null should occur before use, as in -
> quite frankly it is useless to check after as tun cannot be the null
> pointer (the program hasn't crashed):
In
Robert Baron writes:
> Second question:
>
> Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't this
> why memcpy is preferred over strcpy?
According to the man page for memcpy, "The memory areas must not
overlap. Use memmove(3) if the memory areas do overlap."
strcpy wi
Robert Baron writes:
> 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;
> /* res
On 25/11/2013 12:15 AM, Henrique de Moraes Holschuh wrote:
> Well, my best guess is that this is going to be considered "upstream issues"
> by the majority of the package maintainers, and thus they won't get much
> attention downstream (in Debian) until they start causing large headaches.
That's m
On Sat, 23 Nov 2013, Michael Tautschnig wrote:
> This should be taken with a grain of salt. (I'm doing research in the area of
> automated software analysis myself.) It clearly is a well-written paper with a
> nice tool. Yet "unstable code" results from code that would otherwise be
> considered bog
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
On Sun, Nov 24, 2013 at 6:23 AM, Stan Hoeppner wrote:
> On 11/22/2013 7:34 PM, Andrew McGlashan wrote:
>
>> http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c
>
> "the team ran Stack against the Debian Linux archive, of which 8575 out
> of 17432 pack
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 Saturday, November 23, 2013 04:23:05 PM Stan Hoeppner wrote:
> I didn't read the full paper yet, but I'm wondering how/if the
> optimization flag plays a part in this. I.e. does "O2" produce these
> bugs but "OO" (default) or "Og" (debugging) does not?
Or -O3...
--
To UNSUBSCRIBE, email to
On 11/22/2013 7:34 PM, Andrew McGlashan wrote:
> http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c
"the team ran Stack against the Debian Linux archive, of which 8575 out
of 17432 packages contained C/C++ code. For a whopping 3471 packages,
STACK
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.)
[...]
> 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 2013-11-23 15:18, 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?
IIRC memcpy does not, but memmove does.
See: http://linux.die.net/man/3/memcpy
--
To UNSUBSCRIBE, email to debia
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
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
AndrewM
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a s
Hi,
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 code. We implement
this approach
40 matches
Mail list logo
