forked from wangyif2/RE-for-beginners
-
Notifications
You must be signed in to change notification settings - Fork 0
/
signed_numbers.tex
executable file
·56 lines (48 loc) · 4.21 KB
/
signed_numbers.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
\section{\SignedNumbersSectionName}
\label{sec:signednumbers}
\index{Signed numbers}
\newcommand{\URLS}{\url{http://en.wikipedia.org/wiki/Signed_number_representations}}
\IFRU
{Методов представления чисел с знаком ``плюс'' или ``минус'' несколько\footnote{\URLS},
а в x86 применяется метод ``дополнительный код'' или ``two's complement''.}
{There are several methods of representing signed numbers\footnote{\URLS},
but in x86 architecture used ``two's complement''.}
\index{x86!\Instructions!JA}
\index{x86!\Instructions!JB}
\index{x86!\Instructions!JL}
\index{x86!\Instructions!JG}
\IFRU{Разница в подходе к знаковым/беззнаковым числам, собственно, нужна потому что, например,
если представить \TT{0xFFFFFFFE} и \TT{0x0000002} как беззнаковое, то первое число ($4294967294$) больше второго ($2$).
Если их оба представить как знаковые, то первое будет $-2$, которое, разумеется, меньше чем второе ($2$).
Вот почему инструкции для условных переходов~(\ref{sec:Jcc}) представлены в обоих версиях ~---
и для знаковых сравнений (например \JG, \JL) и для беззнаковых (\JA, \JB).}
{The difference between signed and unsigned numbers is that if we represent \TT{0xFFFFFFFE} and \TT{0x0000002}
as unsigned, then first number ($4294967294$) is bigger than second ($2$).
If to represent them both as signed, first will be $-2$, and it is lesser than second ($2$).
That is the reason why conditional jumps~(\ref{sec:Jcc}) are present both for signed (e.g. \JG, \JL)
and unsigned (\JA, \JB) operations.}
\subsection{\IFRU{Переполнение integer}{Integer overflow}}
\IFRU{Бывает так, что ошибки представления знаковых/беззнаковых могут привести к уязвимости
\IT{переполнение integer}.}
{It is worth noting that incorrect representation of number can lead integer overflow vulnerability.}
\IFRU{Например, есть некий сервис, который принимает по сети некие пакеты.
В пакете есть заголовок где указана длина пакета. Это 32-битное значение.
В процессе приема пакета,
сервис проверяет это значение и сверяет, больше ли оно чем максимальный размер пакета, скажем, константа
\TT{MAX\_PACKET\_SIZE} (например, 10 килобайт), и если да, то пакет отвергается как некорректный.
Сравнение знаковое. Злоумышленник подставляет значение \TT{0xFFFFFFFF}. Это число трактуется как знаковое $-1$
и оно меньше чем $10000$. Проверка проходит. Продолжаем дальше и копируем этот пакет куда-нибудь себе
в сегмент данных\dots вызов функции \TT{memcpy (dst, src, 0xFFFFFFFF)} скорее всего,
затрет много чего внутри процесса.}
{For example, we have a network service, it receives network packets.
In the packets there is also a field where subpacket length is coded.
It is 32-bit value.
After network packet received, service checking the field, and if it is larger than,
e.g. some \TT{MAX\_PACKET\_SIZE} (let's say, 10 kilobytes), the packet is rejected as incorrect.
Comparison is signed. Intruder set this value to the \TT{0xFFFFFFFF}.
While comparison, this number is considered as signed $-1$ and it is lesser than 10 kilobytes.
No error here.
Service would like to copy the subpacket to another place in memory and call
\TT{memcpy (dst, src, 0xFFFFFFFF)} function: this operation, rapidly garbling a lot of
inside of process memory.}
\IFRU{Немного подробнее}{More about it}: \cite{Phrack3C0A}.