RabbitMQ integer overflow that leads to heap memory corruption
1–10 of 25 posts
Re: RabbitMQ integer overflow that leads to heap memory corruption
#2Note this is for one of the client libraries - the C library, to be specific - not the server (written predominantly in Erlang, a memory-safe language).
Re: RabbitMQ integer overflow that leads to heap memory corruption
#3Note this is for one of the client libraries - the C library, to be specific - not the server (written predominantly in Erlang, a memory-safe language).
afaict, the issue is in amqp_handle_input()[1]. The fix was
> "add additional input validation to prevent integer overflow when parsing a frame header"
Wouldn't this be a bug in the MQ and not in the C library?
[1] https://github.com/alanxz/rabbitmq-c/commit/fc85be7123050b91...
EDIT: sorry I just realized this is an internal rabbit MQ (C) library, I misunderstood the reference to "C library" thinking it meant the systems g/libc
Re: RabbitMQ integer overflow that leads to heap memory corruption
#4Note this is for one of the client libraries - the C library, to be specific - not the server (written predominantly in Erlang, a memory-safe language).
afaict, the issue is in amqp_handle_input()[1]. The fix was > "add additional input validation to prevent integer overflow when parsing a frame header" Wouldn't this be a bug in the MQ and not in the C library? [1] https://github.com/alanxz/rabbitmq-c/commit/fc85be7123050b91... EDIT: sorry I just realized this is an internal rabbit MQ (C) library, I misunderstood the reference to "C library" thinking it meant the sys…
Nope. It's the C library's problem: who is to say which AMQP implementation is at the other end of the socket?
Re: RabbitMQ integer overflow that leads to heap memory corruption
#5Note this is for one of the client libraries - the C library, to be specific - not the server (written predominantly in Erlang, a memory-safe language).
(Furthermore, checking the git blame, it turns out this bug is my fault, nearly a decade ago. Decoding a size_t out of the packet and then adding a small constant (7) to it turns out to be able to overflow size_t ... sigh. Programming in C should be against some kind of Geneva Convention.)
Re: RabbitMQ integer overflow that leads to heap memory corruption
#6Earlier quoted context omitted.
afaict, the issue is in amqp_handle_input()[1]. The fix was > "add additional input validation to prevent integer overflow when parsing a frame header" Wouldn't this be a bug in the MQ and not in the C library? [1] https://github.com/alanxz/rabbitmq-c/commit/fc85be7123050b91... EDIT: sorry I just realized this is an internal rabbit MQ (C) library, I misunderstood the reference to "C library" thinking it meant the sys…
Nope. It's the C library's problem: who is to say which AMQP implementation is at the other end of the socket?
thanks for clarifying, my bad (I misread the meaning of C library)
Re: RabbitMQ integer overflow that leads to heap memory corruption
#7Note this is for one of the client libraries - the C library, to be specific - not the server (written predominantly in Erlang, a memory-safe language).
(Furthermore, checking the git blame, it turns out this bug is my fault, nearly a decade ago. Decoding a size_t out of the packet and then adding a small constant (7) to it turns out to be able to overflow size_t ... sigh. Programming in C should be against some kind of Geneva Convention.)
So it's a typical 'oh a size_t is big enough I'm never going to have numbers that big' bug? Not that I blame you, I've written enough of those..
Re: RabbitMQ integer overflow that leads to heap memory corruption
#8Note this is for one of the client libraries - the C library, to be specific - not the server (written predominantly in Erlang, a memory-safe language).
(Furthermore, checking the git blame, it turns out this bug is my fault, nearly a decade ago. Decoding a size_t out of the packet and then adding a small constant (7) to it turns out to be able to overflow size_t ... sigh. Programming in C should be against some kind of Geneva Convention.)
> Programming in C should be against some kind of Geneva Convention
Possible and likely in languages other than C. It's just going to hit an out of bounds error when you index the buffer, instead of potentially overwriting an unrelated allocation.
Re: RabbitMQ integer overflow that leads to heap memory corruption
#9Earlier quoted context omitted.
(Furthermore, checking the git blame, it turns out this bug is my fault, nearly a decade ago. Decoding a size_t out of the packet and then adding a small constant (7) to it turns out to be able to overflow size_t ... sigh. Programming in C should be against some kind of Geneva Convention.)
So it's a typical 'oh a size_t is big enough I'm never going to have numbers that big' bug? Not that I blame you, I've written enough of those..
More of a "oh yeah, that's right, C doesn't have integers, just machine words, and it doesn't help you avoid errors when you use machine words to simulate integers" bug. Overflow? You get to keep both pieces.
Re: RabbitMQ integer overflow that leads to heap memory corruption
#10Earlier quoted context omitted.
(Furthermore, checking the git blame, it turns out this bug is my fault, nearly a decade ago. Decoding a size_t out of the packet and then adding a small constant (7) to it turns out to be able to overflow size_t ... sigh. Programming in C should be against some kind of Geneva Convention.)
> Programming in C should be against some kind of Geneva Convention Possible and likely in languages other than C. It's just going to hit an out of bounds error when you index the buffer, instead of potentially overwriting an unrelated allocation.
More that it'd either properly promote from a 64-bit size to a big integer size, or trap on overflow. But either way, yes, a trap is kind of the point. And there are definitely other languages almost equally as toxic as C, yeah.