On Thu, Nov 28, 2013 at 6:10 AM, Wade Richards w...@wabyn.net 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,
Ick.
On Thu, Nov 28, 2013 at 8:28 PM, Joel Rees joel.r...@gmail.com wrote:
On Thu, Nov 28, 2013 at 6:10 AM, Wade Richards w...@wabyn.net 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
On 28/11/13 22:33, Joel Rees wrote:
snipped
[...]
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.
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 throw
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/vulnerabilities as they are
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) wait for upstream
patches
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:
Therefore, a Linux
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
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
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; i100; ++i) {
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.
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
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
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 a
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 -O1
* 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 default
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 proposal
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 with
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 my
Robert Baron robertbartlettba...@gmail.com 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
Robert Baron robertbartlettba...@gmail.com 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
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 Debian
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 bogus
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 code. We
On Sat, Nov 23, 2013 at 6:18 AM, Michael Tautschnig m...@debian.org 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
Deja gnu?
On Sat, Nov 23, 2013 at 10:34 AM, Andrew McGlashan
andrew.mcglas...@affinityvision.com.au 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
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;
}
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
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
[...]
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 before
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
On Sat, Nov 23, 2013 at 1:16 PM, Mark Haase mark.ha...@lunarline.com 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
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 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
[Not sure this really needs to be cc-ed to security@]
On Sun, Nov 24, 2013 at 12:09 AM, Robert Baron
robertbartlettba...@gmail.com 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
On Sun, Nov 24, 2013 at 12:18 AM, Robert Baron
robertbartlettba...@gmail.com 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
On Sun, Nov 24, 2013 at 6:23 AM, Stan Hoeppner s...@hardwarefreak.com 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
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 flowing
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
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
40 matches
Mail list logo
