How does this 16-bit/32-bit bug cause an increase in value?

Index > Windows > How does this 16-bit/32-bit bug cause an increase in value?

Author

Thread

moveax41h

Joined: 18 Feb 2018
Posts: 59

moveax41h 27 Jul 2018, 00:37

This page discusses a specific software exploit. 99% of the page is not relevant, so I'll include the relevant part:

Quote:

SizeOfListInBytes is a DWORD size member of Os2FeaList. If shrinking is needed, the function treats SizeOfListInBytes as a Word member and it updates only the 2 bytes, instead of 4 bytes (with the shrunk size). The 2 most significant bytes remain untouched. This bug causes SizeOfListInBytes to be enlarged instead of shrunk.
If the value of SizeOfListInBytes is in the range of 216, there is no problem and the function works as expected.

However, if the value of SizeOfListInBytes is above the range of 216, it could be enlarged instead of shrunk.

Trying to understand this conceptually, I wrote a fasm program:

Code:

format ELF64 executable

entry main

segment readable executable
include 'io.inc'
include 'unistd64.inc'
main:
        mov eax, 0xFFFFFFFF
        add rax, 1
        mov rax, 0xFFFFFFFF
        add eax, 1
        xor eax, eax
        sub ax, 1
        mov eax, 0xFFFFFFFF
        add ax, 1

        call done

This program doesn't do anything really but it was intended for me to run it through gdb to view the register states.

If I add 1 to ax when eax when eax is full with 0xFFFFFFFF, it just wraps back to 0 again on the low word and remains 0xFFFF on the high word of eax. Similarly, if I load 0x00000000 into eax and then I sub ax, 1, it sets ax to 0xFFFF but again, I don't see how updating specifically the LO WORD of a DWORD could cause an abnormally large number that would not be caused by doing the same operation on the full DWORD.

Can someone with a bit more experience explain shed some light? Thank you.

_________________
-moveax41h

27 Jul 2018, 00:37

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20759
Location: In your JS exploiting you and your system

revolution 27 Jul 2018, 00:54

IIUC the value is read as, say, 0x10001, the code then tries to truncate it to 0x0ffff (i.e. two bytes fewer) and then rewrites only the lower two bytes of the value giving 0x1ffff bytes.

27 Jul 2018, 00:54

moveax41h

Joined: 18 Feb 2018
Posts: 59

moveax41h 27 Jul 2018, 18:50

Ok so basically writing only the lower two bytes causes an improper carry into the 0x10000s place because the rewriting of the lower two bytes causes a carry which ends up there?

27 Jul 2018, 18:50

Furs

Joined: 04 Mar 2016
Posts: 2689

Furs 27 Jul 2018, 19:11

moveax41h wrote:

Ok so basically writing only the lower two bytes causes an improper carry into the 0x10000s place because the rewriting of the lower two bytes causes a carry which ends up there?

There's no carry. What he's saying is that:

1) you have a number larger than 65536, e.g. 0x10001
2) since it doesn't fit in 16-bits, you saturate it to 65535 (0xFFFF) which is the max
3) but you only write back the lower 16-bits, which are now 0xFFFF.

Recall that the number was 0x10001. If you replace the lower 16-bits, you end up with 0x1FFFF, which is obviously larger than 0x10001.

You could say it's the absence of a borrow from the upper 16 bits. Wink

27 Jul 2018, 19:11

moveax41h

Joined: 18 Feb 2018
Posts: 59

moveax41h 27 Jul 2018, 19:16

Aha, thanks Furs... That was a tricky one to understand but that makes a lot of sense. So it's more a problem of not clearing the bits above bit 16 than it is the contents of the low word.

27 Jul 2018, 19:16

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum