3. Buffer Overflow Exploits and Defenses
Вставка
- Опубліковано 29 бер 2017
- MIT 6.858 Computer Systems Security, Fall 2014
View the complete course: ocw.mit.edu/6-858F14
Instructor: James Mickens
In this lecture, Professor Mickens discusses topics related to buffer overflow exploits, including baggy bounds handling, mitigation approaches, and return-oriented programming.
License: Creative Commons BY-NC-SA
More information at ocw.mit.edu/terms
More courses at ocw.mit.edu
I was looking for videos about Return-oriented programming and I saw James Mickens in the thumbnail and I was ecstatic.
Question for the multiple calls to System("/bin/bash"). When we enter the System() function, the first thing the function did was to push %ebp into the stack, thus overwriting the address we saved for the pop-eax gadget. So there should be a 4 bytes or 8 bytes, depending on 32 bits system or 64 bits system you are using, empty space we reserve for the function to place the old ebp inside so not to mess up the address we placed there.
It's just a different calling convention. I'm sure you figured it out by now.
baggy bounds ends at 20:42
thank you ; )
hero
Can we say that 1/16 of memory size is used (or reserved) for baggy bounds table in x86 systems ? (16 is the slot size of course)
"Backward" string storage would allow transferring string data with no danger of buffer overflow, if scaled index addressing was used.
For example, in the line of code below, edi would point to the start of the destination buffer, and ebx would (initially) contain its length.
As each byte was transferred, ebx would be decremented. If decremented below zero, ebx would wrap around to 4 billion, which,
when added to the buffer's start address during the next byte transfer, would exceed the size of any normal-sized data segment.
mov byte ptr [edi + ebx], al
I don't know if backward string storage would be practical, but it seemed like an interesting alternative to arranging for buffer over-
runs to generate GPFs in the usual, RAM-wasting way (placing a buffer near the end of a dedicated segment).
very good lecture
Maybe I'm missing something, but how is char *r = q + 16 supposed to give out an error? Yes, it's way past the allocated 64 bytes(which are in fact 48 bytes. Malloc allocates in multiples of 16 bytes, but it's the address of the beginning of the 48 bytes that's supposed to be a power of two and aligned to the word size of the system, not the size...), but it's simply going to return a pointer to a valid address. Whatever you'll read at that address won't be p, it will be garbage from your process's memory. So in fact it won't error out... it's worse than that. It will act as valid memory and you can read from it. As a matter of fact, you can even write to it, no questions asked! (I'm staring at it in the debugger as I write this). This is an actual undefined behavior.
I didn't know Matt was teaching after finishing his Wii Sports career!
good lecture :)
Awesome
Very nice thank you
thanks learnt a lot
I am not familiar with x86 instruction, or the 'ebp, esp' here, it's frequently mentioned in video. For beginners probably we should study some material to warm-up for the Basics, which one?
For posterity: this is a graduate level course, meaning this is instruction intended for CS students who have already completed a bachelors or equivalent level of education. So the “basics” here is a bachelors degree in software or computer design and engineering.
@@dewdop Eh CS / EE I would say my degree is in electronics engineering technologies and I can still understand the course, but I also independently study system security and exploits and enjoy coding so there is that. Luckily for me 8086 asm isn't too far off of the stuff we used on the 89C420 chips 20 years ago so it has a small bump, but we were taught in ASM / C++ so all the memory leaks and such I'm now understanding them more and what I can do with that.
Thanks
What is the name of the paper that has the full attack mentioned in the second half of the lecture? Broth? Brawf?
Edit: Ohhh, BROP! 😁
00:25 alright, let's get started
nice
Dexploit E-1
in malloc(44) we are telink to alocate 44bytes of memory but it will alocate 64bytes why ?
Because 2^ 5 = 32 and 2^ 6 = 64. and 44 is greater than 32, so it will allocate next higher size of memory.
Well, two years late but... maybe somebody else needs this in the future. The block size (or what he calls the "slot size"... do not confuse it with the alignment!) was decided to be 16 bytes by the teacher. Apparently, the implementation of malloc also usually assigns allocations as multiples of 16 bytes, but it's not guaranteed (which is why he might've chosen that number).
So, considering that your block size has to be a multiple of 16 bytes (can only assign in increments of 16), you cannot allocate just 44 bytes. Malloc is going to see that 44 bytes do not fit nicely into 16 bytes * 2 (since it can only allocate in 16 bytes chunks) and will move the size further by 16, from 16*2 to 16*2 + 16 = 48 bytes (which means you're allocating 48 bytes in total, because malloc is allocating in multiples of 16). Further it will have to check if the address at the beginning of the 48 bytes block is a power of two and then check if the address is aligned to 4 | 8 | etc. bytes, based on the architecture of the system (if it isn't, a padding will be calculated and the resulting 48 bytes will start at a forward address that's a POW2 & aligned to ex. 4 bytes). It's not the size of the block that must be aligned to powers of two, it's the address.
You also have to keep in mind that this allocated memory is not guaranteed to be zeroed (I believe malloc also gives you recycled memory blocks from your process's address space). Also, most OSs allocate memory in 4 kb pages (chunks). I think you can change the size of these pages, but you still have to respect a power of two alignment (Windows supports large pages, which allow you to help the translation lookaside buffer work less in certain scenarios. That way, if pages are bigger, you have to cache less addresses in the TLB for a specific block of memory).
BTW: If you value performance, you should not use a general purpose allocator like malloc. It's better and more performant to reserve + commit VirtualAlloc (on windows) a large chunk of virtual address space, and implement your own allocator using that chunk of memory. VirtualAlloc guarantees that memory is zeroed by default and you can also change memory protections + page size for it. Your memory will be localized, access will be fast and you'll keep actual OS allocations to a minimum this way (malloc can also request memory from the kernel if it runs out of its own chunk, which further slows things down). Further, you can implement various allocators such as: linear allocators, stack based allocators, pool allocators, general purpose allocators involving free lists(which will be faster than malloc itself, but slower then the other custom allocators) etc. None of them is a jack of all trades, and you need to use each of them in specific scenarios (based on your data layout).
P.S: If anything I said is wrong, feel free to correct me.
@@Borgilian wow, thanks for writing that.
@@Borgilianso is it 48 bytes or 64 bytes in the end
ROP at 31:45
gets(buf) is a horrible functions , rather use fgets(). If your web applications allows system() function commands from the public, you are in trouble.
thanks for turkish subtitle
MIT lecture but I saved $60,000
He should teach our lecturer how to teach
Jessy lee Peterson is a smart man.
Is JavaScript still relevant? I think I just found my passion
Lol
Hope you’ve been working to ignite your passion.
Why would they spend so much time talking about baggy bounds if no one uses it in practice 🤔
I've been working on memory safety for years and working on/with arm, so I can tell. Baggy bounds introduced compact shadow space, which is adopted to widely used current memory safety solutions such as Google's sanitizer series. More importantly, its "relative location" using memory alignment inspired up to current on-going security projects to 128 bit Cheri and Morello. It is a "must know" concept if you work on memory safety area.
That "Aja!" is very annoying.