The meaning of CS in buffer overflows?

I figure this is on topic because it is about buffer overflows. I checked
alt.comp.lang.assembler, but it looks a little dead:

I was studying the various articles out there, and I was wondering why a
near return (i.e., from a local function) could cause execution in the
stack segment (i.e., when the ret address has been poisoned), when CS and
SS are different?

Jon.

-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --

In article <41c0ae03$0$74678$14726298@news.sunsite.dk>,
Jon Gomez <jon.gomez.04@cnu.edu> wrote:

>I was studying the various articles out there, and I was wondering why a
>near return (i.e., from a local function) could cause execution in the
>stack segment (i.e., when the ret address has been poisoned), when CS and
>SS are different?

With current 32-bit code, I would expect all segment descriptors would
contain the same value, so all memory accesses are always "near", but
with 32-bit offsets.

Lawrence D'Oliveiro wrote:

> In article <41c0ae03$0$74678$14726298@news.sunsite.dk>,
> Jon Gomez <jon.gomez.04@cnu.edu> wrote:
>
>>I was studying the various articles out there, and I was wondering why a
>>near return (i.e., from a local function) could cause execution in the
>>stack segment (i.e., when the ret address has been poisoned), when CS and
>>SS are different?
>
> With current 32-bit code, I would expect all segment descriptors would
> contain the same value, so all memory accesses are always "near", but
> with 32-bit offsets.

I thought that might be it, but in one of my trial runs, they were different
according to gdb (cs 0x73 versus ss 0x7b). I was reading about "hidden"
values for the registers, that the visible value can be "out of sync" with
the offset it represents, but this seemed to apply usually to shifting
between real and protected mode.

I did another search on assembly groups, this time being a little more
intelligent, I guess, and using smaller strings, and found
comp.lang.asm.x86 (I feel bad for missing such an obvious name). I am
uncertain of the netiquette on cross-posting in a case like this. (I don't
want to be rude.)

Thanks,

Jon.

-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --

Jon Gomez wrote:
> Lawrence D'Oliveiro wrote:
>
>
>>In article <41c0ae03$0$74678$14726298@news.sunsite.dk>,
>> Jon Gomez <jon.gomez.04@cnu.edu> wrote:
>>
>>
>>>I was studying the various articles out there, and I was wondering why a
>>>near return (i.e., from a local function) could cause execution in the
>>>stack segment (i.e., when the ret address has been poisoned), when CS and
>>>SS are different?
>>
>>With current 32-bit code, I would expect all segment descriptors would
>>contain the same value, so all memory accesses are always "near", but
>>with 32-bit offsets.
>
>
> I thought that might be it, but in one of my trial runs, they were different
> according to gdb (cs 0x73 versus ss 0x7b). I was reading about "hidden"
> values for the registers, that the visible value can be "out of sync" with
> the offset it represents, but this seemed to apply usually to shifting
> between real and protected mode.
>
> I did another search on assembly groups, this time being a little more
> intelligent, I guess, and using smaller strings, and found
> comp.lang.asm.x86 (I feel bad for missing such an obvious name). I am
> uncertain of the netiquette on cross-posting in a case like this. (I don't
> want to be rude.)


CS has to point to an executable segment, the data segment
registers (DS, ES, FS, GS, SS) usually point to a read/write
segment. A segment cannot be executable and writable at the
same time, but the segment descriptors can point to the same
linear address range (called segment aliasing).

So, the code segment has to point to a different descriptor
(and different segment number) then the other segments.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:

> Jon Gomez wrote:
>> Lawrence D'Oliveiro wrote:
>>
>>
>>>In article <41c0ae03$0$74678$14726298@news.sunsite.dk>,
>>> Jon Gomez <jon.gomez.04@cnu.edu> wrote:
>>>
>>>
>>>>I was studying the various articles out there, and I was wondering why a
>>>>near return (i.e., from a local function) could cause execution in the
>>>>stack segment (i.e., when the ret address has been poisoned), when CS
>>>>and SS are different?
>>>
>>>With current 32-bit code, I would expect all segment descriptors would
>>>contain the same value, so all memory accesses are always "near", but
>>>with 32-bit offsets.
>>
>>
>> I thought that might be it, but in one of my trial runs, they were
>> different
>> according to gdb (cs 0x73 versus ss 0x7b). I was reading about "hidden"
>> values for the registers, that the visible value can be "out of sync"
>> with the offset it represents, but this seemed to apply usually to
>> shifting between real and protected mode.
>>
>> I did another search on assembly groups, this time being a little more
>> intelligent, I guess, and using smaller strings, and found
>> comp.lang.asm.x86 (I feel bad for missing such an obvious name). I am
>> uncertain of the netiquette on cross-posting in a case like this. (I
>> don't want to be rude.)
>
>
> CS has to point to an executable segment, the data segment
> registers (DS, ES, FS, GS, SS) usually point to a read/write
> segment. A segment cannot be executable and writable at the
> same time, but the segment descriptors can point to the same
> linear address range (called segment aliasing).
>
> So, the code segment has to point to a different descriptor
> (and different segment number) then the other segments.
>
> HTH
>

Wow! That's so neat. I think I get it then.

Thanks,

Jon.
-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --