Re: A Famous Security Bug

Liste des GroupesRevenir à cl c 
Sujet : Re: A Famous Security Bug
De : jameskuyper (at) *nospam* alumni.caltech.edu (James Kuyper)
Groupes : comp.lang.c
Date : 28. Mar 2024, 11:14:24
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uu3fu0$3gmba$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla Thunderbird
On 24/03/2024 19:58, bart wrote:
On 24/03/2024 15:53, Michael S wrote:

#include <stdio.h>
#include <stddef.h>
>
int main(void)
{
   char* p0 = (char*)((size_t)main & -(size_t)0x10000);
   printf("%c%c\n", p0[0], p0[1]);
   return 0;
}
>
>
That would work for small programs. Not necessarily for bigger
programs.
>
 
I'm not sure how that works. Are EXE images always loaded at multiple of
64KB? I suppose on larger programs it could search backwards 64KB at a
time (although it could also hit on a rogue 'MZ' in program data).
 
My point however was whether C considered that p0[0] access UB because
it doesn't point into any C data object.

Here's what the standard says about (size_t)main:
"... the result is implementation-defined. If the result cannot be
represented in the integer type, the behavior is undefined. The result
need not be in the range of values of any integer type."

Here's what the standard says about the conversion to char*:
"the result is implementation-defined, might not be correctly aligned,
might not point to an entity of the referenced type, and might produce
an indeterminate representation when stored into an object."

Alignment cannot be an issue with char*, but the other two problems
remain. In particular, I think you're assuming that, when converted back
to a pointer, the resulting pointer will point 0x10000 bytes further on
in memory. There's no such guarantee.

p0[0] is defined as *(p0+0). As a result, the relevant wording occurs in
the description of the unary * operator.

"If the operand points to a function, the result is a function
designator; if it points to an object, the result is an lvalue
designating the object."

Here's the most fundamental problem: there's no guarantee that p0[0]
points at a C object. There's a very good chance, if the code does what
you're hoping it will do, that it points inside a function. As a result,
the following applies:

"If an invalid value has been assigned to the pointer, the behavior of
the unary * operator is undefined."

So, an implementation is free to define the behavior of such code so
that it does what you want - but the C standard doesn't even come close
to mandating that it do so.


Date Sujet#  Auteur
22 Mar 24 * Re: A Famous Security Bug52James Kuyper
22 Mar 24 `* Re: A Famous Security Bug51bart
23 Mar 24  +* Re: A Famous Security Bug5Keith Thompson
23 Mar 24  i`* Re: A Famous Security Bug4Kaz Kylheku
23 Mar 24  i `* Re: A Famous Security Bug3David Brown
23 Mar 24  i  `* Re: A Famous Security Bug2bart
24 Mar 24  i   `- Re: A Famous Security Bug1David Brown
23 Mar 24  `* Re: A Famous Security Bug45James Kuyper
23 Mar 24   `* Re: A Famous Security Bug44bart
23 Mar 24    +* Re: A Famous Security Bug37David Brown
23 Mar 24    i`* Re: A Famous Security Bug36bart
24 Mar 24    i +* Re: A Famous Security Bug29David Brown
24 Mar 24    i i`* Re: A Famous Security Bug28bart
24 Mar 24    i i +* Re: A Famous Security Bug12Keith Thompson
24 Mar 24    i i i+- Re: A Famous Security Bug1David Brown
24 Mar 24    i i i+* Re: A Famous Security Bug3Michael S
25 Mar 24    i i ii+- Re: A Famous Security Bug1David Brown
25 Mar 24    i i ii`- Re: A Famous Security Bug1Keith Thompson
25 Mar 24    i i i`* Re: A Famous Security Bug7bart
25 Mar 24    i i i `* Re: A Famous Security Bug6Michael S
25 Mar 24    i i i  +* Re: A Famous Security Bug4bart
25 Mar 24    i i i  i`* Re: A Famous Security Bug3David Brown
25 Mar 24    i i i  i `* Re: A Famous Security Bug2Malcolm McLean
25 Mar 24    i i i  i  `- Re: A Famous Security Bug1Michael S
25 Mar 24    i i i  `- Re: A Famous Security Bug1David Brown
24 Mar 24    i i `* Re: A Famous Security Bug15David Brown
25 Mar 24    i i  `* Re: A Famous Security Bug14Michael S
25 Mar 24    i i   `* Re: A Famous Security Bug13David Brown
25 Mar 24    i i    +* Re: A Famous Security Bug3Michael S
25 Mar 24    i i    i+- Re: A Famous Security Bug1David Brown
25 Mar 24    i i    i`- Re: A Famous Security Bug1bart
25 Mar 24    i i    `* Re: A Famous Security Bug9bart
25 Mar 24    i i     +* Re: A Famous Security Bug7Michael S
25 Mar 24    i i     i`* Re: A Famous Security Bug6bart
25 Mar 24    i i     i +- Re: A Famous Security Bug1David Brown
25 Mar 24    i i     i `* Re: A Famous Security Bug4Michael S
25 Mar 24    i i     i  `* Re: A Famous Security Bug3bart
26 Mar 24    i i     i   `* Re: A Famous Security Bug2Michael S
26 Mar 24    i i     i    `- Re: A Famous Security Bug1bart
25 Mar 24    i i     `- Re: A Famous Security Bug1David Brown
24 Mar 24    i `* Re: A Famous Security Bug6Michael S
24 Mar 24    i  `* Re: A Famous Security Bug5bart
25 Mar 24    i   +* Re: A Famous Security Bug2Michael S
25 Mar 24    i   i`- Re: A Famous Security Bug1Michael S
25 Mar 24    i   +- Re: A Famous Security Bug1David Brown
28 Mar 24    i   `- Re: A Famous Security Bug1James Kuyper
23 Mar 24    +- Re: A Famous Security Bug1Tim Rentsch
24 Mar 24    +- Re: A Famous Security Bug1Michael S
24 Mar 24    +* Re: A Famous Security Bug3Michael S
24 Mar 24    i`* Re: A Famous Security Bug2bart
24 Mar 24    i `- Re: A Famous Security Bug1Michael S
28 Mar 24    `- Re: A Famous Security Bug1James Kuyper

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal