Software Security Study Group Report 

Week 2

In the second week, our Software Security Study Group started with a reminder to previous week subjects. Later, we discussed some limitations of applying perfect secure one-time pads and perfect secrecy. In order to achieve limitations and implement acceptable security to our data, we defined “Computational Secrecy” and proved the secrecy with use of mathematics.

We mainly discussed on one of the essential requirement of cryptography, randomness. Since the computers are known state machines the randomness would be hard to achieve. After acknowledging the true randomness we have defined the pseudo randomness and its requirements. We have shown how to achieve security of pseudo randomness and its importance on security. We have supported our acknowledgments with mathematical proofs and proof of concepts. We also have experienced with various real world cryptographic algorithms.

After the cryptography session and the sandwich break we have started discussing low level security of software. We have discussed various vulnerabilities lying inside our low level code. We started with a reminder of the buffer and discussed the overflows on various code and data stored locations. We have discussed other exploits lying in the memory like code injection and explained some ideas behind protective measures. We have touched on the topic of format string vulnerabilities and how it could be used to leak data and exploit the application.

In the second part of our Software Security Study Group, we focused on Low-Level Security. At first we explained the Safe Memory Model ( https://bit.ly/2GPkp9i ), Type Safe Techniques           ( https://bit.ly/1CfdKYv ), ROP ( https://ubm.io/2Hs4PgQ , https://bit.ly/2v0OTzu ) for exploitation, methods of prevention of buffer overflows attack (Canary, DEP, NX, ASLR, etc).

And we talked about a return to libc attack. Finally, we talked about Control-flow integrity.

Other than that, short information is below:

• The use of smart pointers will be more secure in C++.

• We need to pay attention to the libraries we use.

• Using fgets instead of gets is more secure.

• Valgrind tools that can automatically detect many memory management and threading bugs,

memory leak and profile your programs in detail.

After the second lecture, we solved some CTF questions about first lesson's low level topics

https://www.coursera.org/learn/software-security/home/week/3

https://www.coursera.org/learn/cryptography/supplement/Qn5da/week-3

 

See you next week!