2. Control Hijacking Attacks
Vložit
- čas přidán 29. 03. 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 continues the topic of buffer overflows, discussing approaches to such control hijacking attacks.
License: Creative Commons BY-NC-SA
More information at ocw.mit.edu/terms
More courses at ocw.mit.edu
I finally understand how doors work. Thank you MIT!!
I was wondering how this comment would fit into the context of this video. Figured that out in the first few seconds lol.
$80k a year in tuition and can't afford a can of three in one oil or wd40.
The fortran/cobol comment was the first time I've ever laughed out loud listening to a lecture. This whole presentation was super interesting and really well delivered
the proper term for bp / ebp register is "base pointer" not "break pointer"
OMG that door
Great lecture. Great style. I question the cost/benefit of the defenses. 1) Hacker does remote overflow of custom code, cannot see core dump so extremely hard to write an overflow without knowing the stack structure 2) Hacker overflows known piece of open source code. Hacker will see all the defenses (canary) and plans accordingly. SUMMARY: Best defense is bounds and input checking (following through on pointer dereferences), static code analysis, code review the diffs, training on OWASP top 10.
Pretty sure it's a mistake to include C# in the list of languages that are safe from allowing raw pointer access.
Really nice lecture. The professor presents the information in a pleasant way.
vinod kambli sir.. you are great
Wtf 🤣
Coolest lecture ever.
too much door noise...needs some oil..
or the students could learn to tell the time
Neri Matrixx This is just the second class genius. How many projects do you need to handle in that time? Mr. graduate?
The closed captions need to be reviewed by someone who understands the material. There are several mistakes.
1:22:00 When you check whether p' is out of bound, you actually have access to p. That means you can get the binary logarithm of the allocation size just from the table[p>>slot_size]. Why do you want the table to cover all allocation size of p?
This lecturer is awesome
Hmm not a newbie lecture but interesting for sure
excellent professor, but has got an iconic handwriting.
It's amazing how someone not putting WD-40 on a hinge can make a lecture incredibly hard to learn from.
5:29 buffer grows downwards in stack, lol
"imagine what happened in my parent time, if they did not understand things, they had to go home "😂
Terrific lecturer.
Those are squeaking folding chairs, not a door
How it would work in practical observation
STOP COMING THROUGH THE DOOR. JUST STOP. GO HOME. PLEASE.
11:49 great info
MIT should mention that there are prerequisite to this course. You can’t possibly understand any of this unless you are highly proficient in programming/coding and how it works.
The syllabus lists 6.033 Computer System Engineering as a prerequisite. See the course on MIT OpenCourseWare for more info at: ocw.mit.edu/6-858F14. Best wishes on your studies!
@@mitocw hello, thank you so much for reply. I will first learn 6.033 now.
@@mitocw can you please provide latest 6.033 course? The year 2005 one has first 3 lectures missing.
I'm not sure about this I'm no where near the level of this course but the overall message is pretty easy to understand if you have some barebones knowledge of x86 assembly, C and how all of it works together, sure you may not get the nitty gritty of what this man is completely writing out but in terms of understanding buffer overflow and some of the other high level stuff he speaks about you should be able to understand it.
Or perhaps I'm just telling myself I understand it, no clue lol however I truly do feel I understand at a high level what is being explained and this lecture and the prior one were great, hope to see how the rest of this course goes.
@@mitocw i have a degree in physics and worked on the nova and found this lecture really excellent and the lecturer has a great sense of humor for a subject so heavy. Extremely impressed
No language can be fast and safe at the same time.
is there an earthquake happening during this lecture or is it just me?
Professor CJ ?
Summary: despite the trend toward high and tight jeans, always keep your pointers low and loose, ‘baggy bound.’
Stack canaries value is something like default value case if there won't any match of cases to be executed in Switch Statement
That creaking door needs to be fixed asap super distracting at the start.
There is no JIT for python (Cpython atleast). Hence when it comes to C vs Python, definitely C outdoes python in perf
There should be no comparison between high and low level language. of course, C outdoes any higher level not just Python.
C outperfs every language
Depends on the application. For an I/O bound application there can be very little difference.
Python is just a tool for calling c and Haskell function
I was good until that buddy/baggy allocator thing came.. Then I realized this has prerequisites.
If you watch the next lecture he goes over more in-depth on buffer overflows and the baggy bounds system.
Rust solves a lot of the language problems
Ambitionz Az a Programmer
Chris Rock is a good teacher
lol
Too much door noise...needs some oil in the future to control our own hijacking problems.
Sanitize. Sanitize all input. Alert log anything suspicious.
Alert log door noise. Lubricate all inputs. Sanitize anything suspicious.
lol
What is WRONG with your classroom? Get some hecking oil ....
Save the human race and earth
Please no more squeaking!!!!
spoiler alert the most disgusting door and handwriting in the same video
Wrong. JavaScript programs suffer from other vulnerabilities. C and C++ are much harder to hack
Stop moving the camera so much Jesus Christ it's so annoying.
Decent lecture but guy is somewhat flippant/casual in his opinions about languages. For example does the potential for buffer overflows really imply that C is "...the spawn of the devil?" C is one of the five most important inventions in the history of programming. So 1) what has this professor done? And 2) it is very possible to write and patch apllications. There is no language that is impenitrable right now: not java, go, python, etc. So I'm not convinced yet that the answer is better memory "management".
better memory management gets rid of a class of errors, and thus a large percent of security bugs. Now there's Rust that doesn't have to sacrifice speed to do it.
The more of this I watch the less I am impressed because a lot of the arguments the professor makes do not seem well thought-out. E.g. writing a parser in Python: yeah, okay. But...no one does that in C...ever. So the profundity of that point is lost on me. E.g. "...javascript to run at 2x..." He's comparing the speed of C with Javascript in a lecture on security? Wuh...? To me his wires are very crossed on that point. I'm confused: it's like he thinks software engineers are out writing web apps in C...? They are not...ever. But yes...network applications are written in C, lol...because of its superior speed. Maybe...maybe Go will overtake C...fine. But ya know what? The original Go compiler was written in uhhh...C! And the other is written in C++, lol.
In the most popular version of python cpython the code your running is just someone else’s c function