4 ms·

Let me see if I got this right, This can be used to DOS a system by consuming all free memory? In the CVE it almost hints that this specifically is UDP related

Let me see if I got this right, This can be used to DOS a system by consuming all free memory? In the CVE it almost hints that this specifically is UDP related. Am I right in thinking this?

0x0 10y ago
It says in the post that you can execute arbitrary code in the kernel. So, full compromise of the system. (In the case of Docker, perhaps you can even escape to the root system?)
- andrewstuart2 10y ago
  AFAIK Docker is still not considered ready to run untrusted code on shared machines. If you want to run untrusted code, you should just use a VM anyway.
  - raesene6 10y ago
    Even with a VM you need to be somewhat careful as hypervisor breakouts are not unknown.
    - jeffmcjunkin 10y ago
      Absolutely. That said, the Linux kernel is a helluva lot more attack surface than the relatively few hypercalls provided by most Type 1 hypervisors.
- staticassertion 10y ago
  Should be able to escape docker with this. Docker provides host kernel access, so if you get the kernel you're good to go.
geofft 10y ago
This is a double-free vulnerability. In userspace, this would basically be void *x = malloc(16); free(x); ... free(x); When malloc makes the allocation, it actually allocates a bit more than 16 bytes so it knows how much to free. Usually what it'll do is store a structure right before the pointer it returns; for instance, it might allocate 24 bytes, use the first 8 bytes to store the number 24, and then return the rest of that allocation. Then, when free is called, it subtracts 8 from what it was given, and frees that many bytes. (More complicated malloc implementations will have more complicated structures, possibly including pointers to other, shared structures.) If you call free a second time on the same pointer, a lot of things could happen. In particular, if there was another call to malloc() in between, it might reuse that same location, and you might free that. Or if some other sequence of allocations happened, there might be a completely nonsensical number stored at x-8. If the second call "frees" data that's still in use, two parts of the program will be writing to the same memory. Maybe one thing is storing the return value of a call, and the other thing is storing the current UID. So when the first thing writes 0, now you're UID 0. Alternatively, if the second call frees something nonsensical, you might "free" memory that was never the allocator's in the first place - and cause the next call to malloc() to return a pointer to something important elsewhere in memory, perhaps even the program's stack frame. If the program then reads attacker-controlled data into that newly-allocated memory, the attacker takes over the program's control flow. DCCP is a protocol that is kind of like UDP, in that it's message-oriented, but kind of like TCP, in that it's reliable and implements congestion control. It's not very common, and uncommon networking protocols have been a historic good source of vulnerabilities in the Linux kernel.
- jtchang 10y ago
  I assume the reason why this can happen is because the default implementation of malloc/free doesn't check if the pointer has already been free'ed right? And the reason it doesn't check is because of performance reasons?
  - coldpie 10y ago
    How do you detect a "pointer that has already been freed"?
    - aseipp 10y ago
      You overwrite the page you just freed (e.g. point it entirely to a fixed page of junk bytes) or mark it as PROT_NONE immediately upon free().
    - mikeash 10y ago
      You could keep a separate list of all live allocations. If free() is called with a pointer that's not on the list, it's an error. This won't immediately detect the case where you free, something else mallocs in that exact spot, and then you free again. It will eventually catch it when the something else tries to call free. It will catch cases where the second free call happens before the memory is reused, or when the memory is reused but the new chunk starts earlier. I assume this isn't done because maintaining and checking the list would cost too much.
      - xenadu02 10y ago
        If the bookkeeping weren't so massive you could cycle through the entire 64-bit address space before re-issuing the same memory address. That would be similar to a bump allocator; once all the allocations on a page were freed you could unmap it so except for pathological cases you couldn't explode the number of page table entries too horribly. At 1 TB/sec of allocations it would take 500 years to reach the end of the 64-bit address space in the kernel. (It's actually 544 years ignoring leap years and leap seconds, but subtract 44 years for reserved address ranges). The benefit would be making it impossible to use-after-free because the same address would never be re-used.

Let me see if I got this right, This can be used to DOS a system by consuming all free memory? In the CVE it almost hints that this specifically is UDP related. Am I right in thinking this?

0x0 10y ago

It says in the post that you can execute arbitrary code in the kernel. So, full compromise of the system. (In the case of Docker, perhaps you can even escape to the root system?)

andrewstuart2 10y ago
AFAIK Docker is still not considered ready to run untrusted code on shared machines. If you want to run untrusted code, you should just use a VM anyway.
- raesene6 10y ago
  Even with a VM you need to be somewhat careful as hypervisor breakouts are not unknown.
  - jeffmcjunkin 10y ago
    Absolutely. That said, the Linux kernel is a helluva lot more attack surface than the relatively few hypercalls provided by most Type 1 hypervisors.
staticassertion 10y ago
Should be able to escape docker with this. Docker provides host kernel access, so if you get the kernel you're good to go.

geofft 10y ago

This is a double-free vulnerability. In userspace, this would basically be void *x = malloc(16); free(x); ... free(x); When malloc makes the allocation, it actually allocates a bit more than 16 bytes so it knows how much to free. Usually what it'll do is store a structure right before the pointer it returns; for instance, it might allocate 24 bytes, use the first 8 bytes to store the number 24, and then return the rest of that allocation. Then, when free is called, it subtracts 8 from what it was given, and frees that many bytes. (More complicated malloc implementations will have more complicated structures, possibly including pointers to other, shared structures.) If you call free a second time on the same pointer, a lot of things could happen. In particular, if there was another call to malloc() in between, it might reuse that same location, and you might free that. Or if some other sequence of allocations happened, there might be a completely nonsensical number stored at x-8. If the second call "frees" data that's still in use, two parts of the program will be writing to the same memory. Maybe one thing is storing the return value of a call, and the other thing is storing the current UID. So when the first thing writes 0, now you're UID 0. Alternatively, if the second call frees something nonsensical, you might "free" memory that was never the allocator's in the first place - and cause the next call to malloc() to return a pointer to something important elsewhere in memory, perhaps even the program's stack frame. If the program then reads attacker-controlled data into that newly-allocated memory, the attacker takes over the program's control flow. DCCP is a protocol that is kind of like UDP, in that it's message-oriented, but kind of like TCP, in that it's reliable and implements congestion control. It's not very common, and uncommon networking protocols have been a historic good source of vulnerabilities in the Linux kernel.

jtchang 10y ago
I assume the reason why this can happen is because the default implementation of malloc/free doesn't check if the pointer has already been free'ed right? And the reason it doesn't check is because of performance reasons?
- coldpie 10y ago
  How do you detect a "pointer that has already been freed"?
  - aseipp 10y ago
    You overwrite the page you just freed (e.g. point it entirely to a fixed page of junk bytes) or mark it as PROT_NONE immediately upon free().
  - mikeash 10y ago
    You could keep a separate list of all live allocations. If free() is called with a pointer that's not on the list, it's an error. This won't immediately detect the case where you free, something else mallocs in that exact spot, and then you free again. It will eventually catch it when the something else tries to call free. It will catch cases where the second free call happens before the memory is reused, or when the memory is reused but the new chunk starts earlier. I assume this isn't done because maintaining and checking the list would cost too much.
    - xenadu02 10y ago
      If the bookkeeping weren't so massive you could cycle through the entire 64-bit address space before re-issuing the same memory address. That would be similar to a bump allocator; once all the allocations on a page were freed you could unmap it so except for pathological cases you couldn't explode the number of page table entries too horribly. At 1 TB/sec of allocations it would take 500 years to reach the end of the 64-bit address space in the kernel. (It's actually 544 years ignoring leap years and leap seconds, but subtract 44 years for reserved address ranges). The benefit would be making it impossible to use-after-free because the same address would never be re-used.