Comments 10
Ну тем не менее в каких-то ЯП проще отстрелить.
Да подобные высказывания всегда были. Типа язык А гарантирует защиту от проблемы Б. Хочется людям верить в сказку. Помню, когда-то любили говорить, что на Java невозможны утечки памяти…
Основная опасность Heartbleed была в возможности получить от сервера данные за пределами сетевого буфера, т.е. байты, находящиеся далее на стеке или куче (где, теоретически, могли находится секретные ключи, пароли и т.п., которые клиент ну никак не мог получить). Ваша программа не демонстрирует этой проблемы, она лишь позволяет получить назад байты, которые мы только что отправили, и не более того. Для того, чтобы воспроизвести эту проблему на Rust, нужно выйти за пределы буфера, а не только прочитать с него больше байт, чем требуется, что Rust не позволит сделать (если, конечно, вы не используете небезопасные (unsafe) блоки).
Во-первых, там был свой аллокатор памяти. Ни Rust, ни Ada не справятся с такой ситуацией. У них мощные bound checker'ы, но если пользователь выделил себе буфер и ковыряется в нём сам — ничего не попишешь. Во-вторых, длина генерируемого в ответ сообщение основывалось только на поле входящего сообщения, игнорируя длину самого этого сообщения. В-третьих, буфер использовался несколько раз без обнуления.
Да, и пост не мой — это перевод.
The RFC 6520 Heartbeat Extension tests TLS/DTLS secure communication links by allowing a computer at one end of a connection to send a «Heartbeat Request» message, consisting of a payload, typically a text string, along with the payload's length as a 16-bit integer. The receiving computer then must send exactly the same payload back to the sender.
The affected versions of OpenSSL allocate a memory buffer for the message to be returned based on the length field in the requesting message, without regard to the actual size of that message's payload. Because of this failure to do proper bounds checking, the message returned consists of the payload, possibly followed by whatever else happened to be in the allocated memory buffer.
Да, и пост не мой — это перевод.
И все таки сравнение не корректно. Согласно приведенной вами же цитате, выделялся буфер размера X под данные ответа, а отсылалось данных больше чем X, что, как утверждается, в Rust'е сделать невозможно. В вашем же примере автор взял буфер размера X и прочитал из него не более X данных.
Ещё раз: в OpenSSL была своя обёртка вокруг malloc, поэтому для C всё выглядело нормально, чтение происходило из ранее выделенного буфера. Для Rust в примере всё выглядит нормально по той же причине.
Вот две статьи того же автора, анализирующие heartbleed:
Вот гневный mail Theo de Raadt насчёт костыля вокруг malloc: article.gmane.org/gmane.os.openbsd.misc/211963.
Вот две статьи того же автора, анализирующие heartbleed:
- www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
- www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
Вот гневный mail Theo de Raadt насчёт костыля вокруг malloc: article.gmane.org/gmane.os.openbsd.misc/211963.
Согласен. Утверждать что доступ к выделенному необнуленному буферу и доступ к почти любому участку памяти это одно и то же как то странно.
Аналог на haskell, но так написать можно только специально. )
module Heartbleed where
import System.IO
import Data.Array.IO
import Data.Word
copy :: String -> String -> IOUArray Int Word8 -> IO ()
copy from to buffer = do
from' <- openFile from ReadMode
to' <- openFile to WriteMode
c <- hGetArray from' buffer 250
hPutArray to' buffer 250
hClose from'
hClose to'
main = do
buffer <- newArray_ (0,250)
copy "yourping" "yourecho" buffer
copy "myping" "myecho" buffer
~/Tmp -$ cat yourecho limbo-home@chemist :)
#i have many secrets. this is one.
�8d��=��d�T�% ~/Tmp -$ cat myecho limbo-home@chemist :)
#i know your
secrets. this is one.
�8d��=��d�T�%
Sign up to leave a comment.
Heartbleed на Rust