SDL Episode50

From Paul's Security Weekly
Jump to: navigation, search

Secure Digital Life #50

Recorded on January 30, 2018 at G-Unit Studios in Rhode Island!

Episode Audio

Coming soon!


  • Doug White
    Cybersecurity professor, President of Secure Technology, and Security Weekly network host.
  • Russell Beauchemin
    Cybersecurity & Network Security Program Advisor and Director of Instructional Support & Learning Innovation at Roger Williams University.
  • Topic: Buffer Overflows

    Wolf in the Fold Part 2.14159265

    Continuing the study of overflow behavior. //which sounds like something from the plumber's conference

    Review of Stack and Heap Allocations

    • Stack Allocations are fixed memory assignments when a program is compiled
    1. So int x == 2; will assign 32 bits to the pointer to x and put the integer 2 in it.
    • Heap allocations are "on the fly" memory assignments which occur as the program runs
    1. so new int y == 47 will grab 32 bits of memory and assign it to the pointer to y and put 47 in that location
    • //NOTE: This is not an attempt to write C/C++ code but is just pseudocode illustrations
    • So, a buffer overflow type piece of code
    1. for (int x = 0; x < 100;)

    new int y = y+1;


    • Now, if y < 4,294,967,295 (billion) then all is well but if we add one more (which the above will do) then that number is actually 33 bits. What will result from this weirdness? Who knows, but that is a buffer overflow.
    • Now, let's make it worse. Everything is better when it's worse.
    • What if I use some vectors:

    x   y
    0   0
    1   1
    2   1
    3   2
    4   3
    5   5

    • Explain the linked list:
    1. If we have a pointer to 0, then 0 has a pointer to 1 and so on. We can define this thing as a linked list and it's how a low level structure works in memory.
    • if we are also doing other things like say:

    z    q
    0    1
    1    3
    2    5
    3    7

    • This is also stored somewhere. So what if X5 instead of being the end is somehow "redirected" past the end of x and into z? This type of pointer redirect is a stack overflow of sorts. So, what happens is we may be able to see the values of z by overrunning x.
    • Likewise, a different kind of attack is to simply change the pointer for say x1 to z1 and see what is there (that is not a buffer overflow but rather just a security flaw that would let you do that)
    • In fact, a security flaw then could allow you to dump the contents of memory just by overrunning everything
    1. *let x == pointer to 1 bit of memory
    2. *print x
    3. *x = x + 1
    4. *lather, rinse, repeat. Now, we could literally see the entire contents of active memory
    • So, this brings up the idea of how things are stored again. What if you KNEW that the login and password of a user was stored at location a(27) in memory and that a(27) was 128 bits long (two 8 byte buffers). So, that it looked like:
    1. *bbdwhitebblucky7
    • The OS blocks attempts to access to a(27)
    • So, I do this:

    x == a(26) // no block there
    x = x+1 // now I am actually incremented into a(27) rather than setting something to a(27)

    • If the system is poor, this type of overrun, may work and suddenly I can write a nasty tool that overruns my space and grabs data from a(27) and the next 128 bits and returns it to me.
    • This is the same idea of putting something too big in a too small space and then returning it:
    • Let's say I can create a variable which is a heap variable and I know that by creating it as a pointer to a place, I can try to overrun that space. So:
    1. x is a pointer to memory set to a(26) but I create it such that it is 256 bits long instead of the 128 bits in a(26) so now, I actually contain the "restricted" space of a(27) on the back end of a(26). Drop the first 128 bits and I have the username and password right out of memory.

    //Interlude on Memory Forensics

    //Next week, Doug and Russ will finally explain Spectre and Meltdown