| Channel | Publish Date | Thumbnail & View Count | Download Video |
|---|---|---|---|
 | Publish Date not found |  0 Views |
The slides themselves are subject to the Creative Commons license CC-BY-SA and the images used are licensed as individual captions.
The topics of this lecture include:
Troubleshooting
Careful design and testing are important to avoid introducing vulnerabilities
After a software is created (and during the development process), programs can be tested with or without access to the source code to look for vulnerabilities
After a vulnerability is discovered, you can create a proof of concept/exploit or develop a solution to the problem.
(FOSS vs. proprietary software)
Zero days
A zero-day vulnerability is a new security issue that has been discovered
If a security researcher finds a bug that the software developers are unaware of, it can have serious security consequences.
Like worms or targeted attacks
If they then weaponize the attack and create an exploit for the attack, this is called a zero-day exploit if there is no currently available fix to defend against the attack.
Disclosure of security vulnerabilities
The way in which vulnerabilities should be disclosed in a hotly debated topic
Responsible/coordinated disclosure involves contacting affected suppliers first and giving them time to fix the problem. There is usually a deadline before the disclosure goes public.
Full disclosure means that all technical details of a security vulnerability are made public without first giving the provider the opportunity to fix it.
Our Vulnerability Disclosure Policy
1) Complete the disclosure form by replacing the yellow fields.
2) Send it to the safety officer(s) in the company
3) Apply for a CVE
4) After (not earlier than) 15 days after step 2, report to CERT/CC
5) After CERT publishes the details (typically 45 days later), you may (at your discretion) publicly discuss the vulnerability or publish other details and code, for example via a blog post or by submitting code to MSF.
Further information can be found on the module page
If you wish to use a different method of vulnerability disclosure, please discuss this with your tutor in advance.
find mistakes
If you have access to the source code:
Manual code review
Static analysis: software for automatic code analysis
If you have access to the source code or not:
Reverse engineering: as above
Binary static analysis
Fuzzing to perform “random tests”
Static analysis
Static analysis can support code review to automatically analyze code and detect common programming errors
Ideal for detecting errors that can be detected automatically, such as:
Buffer overflows, memory errors, unsafe functions
Some tools have a high false positive rate
You won't see everything!
Static analysis tools
There are numerous static analysis tools available. Some FOSS C/C++ tools include
CppCheck (aims for 0 false alarms)
Error Finder
RATS
VCG (VisualCodeGrepper)
Oink (includes Cqual++)
Many other tools:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Easy to combine: They offer different coverage
Static analysis tools
Coverity Scan Static Analysis, free for FOSS projects
Please take the opportunity to connect with your friends and family and share this video with them if you find it useful.
