full-disclosure - gcc: Internal compiler error: program cc1 g ot fatal signal 11

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <200401091558.i09FwwFg026224@mailserver2.hushmail.com>
From: mr.pink at hushmail.com (mr.pink@...hmail.com)
Subject: gcc: Internal compiler error: program cc1 g ot fatal signal 11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 09 Jan 2004 02:34:03 -0800 John.Airey@...b.org.uk wrote:
>Not wishing to spoil the party, but what security issue does this
>prove?
>That it's possible to write a C program that segfaults?

    Before the regular security geniuses started replying with confirmations
that the binary produced by gcc crashes on runtime, the focus was aimed
at gcc crashing while compiling the given source. Unfortunately for the
original poster, and everybody that believes they have helped the security
community by confirming the presence of this bug on various gcc versions,
 it is about as useful as politely asking your target to manually send
a SIGSEGV signal to gcc.

(gdb) x/i $eip
0x8079d95 <expand_expr+4765>:   movsbl (%edx,%eax,1),%eax
(gdb) x/i $edx + $eax
0xd31e78d6:     Cannot access memory at address 0xd31e78d6

    The address that the movsbl instruction is _reading_ from isn't mapped
into the process's address space. Even if a valid address was accessed
(a lower value for the array index), the value read and most likely used
as an operand to the mov/push instructions in the resulting binary will
be garbage from gcc's memory. Seeing as gcc contains no sensitive data,
 this fails to be useful.

    Gcc bugs do exist, but in a much more serious form. A compiler can
create vulnerable assembly code from seemingly safe C code. Since most
people either lack the time to audit a binary, or perhaps the compiler
theory needed to find this class of bug, this issue most likely affects
every one of you.

    As to the person that made the groundbreaking discovery that 'printf("%c\n",
"msux"[3]);' does not crash at runtime -- no shit, Sherlock.

>Try writing linked
>lists programs (or for more fun, doubly linked lists programs).
>Until you
>get it right, most of your efforts will segfault (at least, that's
>my
>experience).

    Sounds like programming by coincidence to me, perhaps you should
consider increasing your so-called "experience", maybe starting with
an introduction to C.


Have a nice day.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.3

wkYEARECAAYFAj/+z0sACgkQ00PjdRJ1pOc+uACgrVxr+z1NIikwNUvGUdN7mh8NhKQA
oLxiLvOwMD4wNM8mX43rjGWiUZel
=wvZI
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427