Code coverage analysis is used in software testing to discover untested pieces of an application. Gathering code coverage data may also be useful for fuzzing. Basically it may help to figure out which parts of a program were not reached during fuzzing. This info can then be used to improve the fuzzer.
Let’s try to gather some code coverage data during fuzzing. As an example, we’re going to test picotls with tlsbunny. Picotls is an implementation of TLS 1.3 protocol written in C, and tlsbunny is a framework for building negative tests and fuzzers for TLS 1.3 implementations. We’re going to use gcov for gathering code coverage data, and lcov for creating a report.
Picotls is a TLS 1.3 implementation written in C. At the moment of writing this post, picotls implements TLS 1.3 draft 26.
I have been experimenting with TLS 1.3 in tlsbunny project. This is a framework for building negative tests and fuzzers for TLS 1.3 implementations. For example, tlsbunny has several simple fuzzers for TLS structures like TLSPlaintext, Handshake, ClientHello, etc. It would not be worse to run those fuzzers against picotls server.
OWASP Dependency Check is a well known open-source tool which can track dependencies in your project and identify components with known published vulnerabilities. The tool supports multiple languages and platforms such as Java, .NET, Ruby and Python. One of the simplest ways how you can use Dependency Check in your project is just to run it manually. This way has at least one disadvantage: you have to make sure that you run the tool regularly. Fortunately there is a couple of ways how you can automate this process.
But unfortunately sometimes it’s not enough just to automate something. If the tool reports a vulnerability it means someone has to fix it. At least it would be good to evaluate the problem. In a perfect world, all issues are addressed immediately, but in the real world, development teams always have no time for that. Besides integrating Dependency Check to CI/CD, there may be a couple of other steps to get vulnerable dependencies updated.
Here is a brief overview which describes how TLS can be used for establishing a secure TLS connection. First, we briefly discuss what SSL/TLS protocols are. Next, we’ll talk about secure TLS protocol versions and parameters. Finally, we’ll describe how TLS can be parametrized securely.
For those who are interested in machine learning and/or security, here is a research which discusses extracting secrets from machine learning systems:
The authors say deep learning models can memorize secrets which the training data may contain. Then the authors provide a couple of algorithms which were successfully used for extracting sensitive data from black box machine learning systems. The authors also show that unintended memorization is not the result of overfitting. Finally, they discuss several ways to mitigate the problem.
According to Mr. Schneier, there is a lot more research to be done here. So good luck :)
Java 10 is coming in March 2018. This release contains quite a lot of enhancements in the JVM. But it looks like JDK users are mostly interested in one particular update in the Java Language – type inference to declarations of local variables with initializers. Besides updates to the Java Language and JVM, Java 10 contains another update which together with the six-month release model has been bothering the Java community for several months.
Here is a digest of the rest of the main features in Java 10 which weren’t covered in the previous post. Enjoy!
Java 10 should be released in Mar 2018. It’s going to be the next short-term release after Java 9 which was released in Sep 2017.
After I had left the Java Team at Oracle in the end of 2017, and moved to another side of Atlantic Ocean, I made a New Year’s promise that I’ll keep myself updated about changes in Java at least for a year.
Since Java 10 is coming, it’s time to have a look at the JEPs (Java Enhancement Proposal) targeted to Java 10. Here is a digest of the main features which are planned to be delivered in Java 10. Enjoy!
DNS rebinding attacks have been known for quite a long time. For example, Stanford Web Security Research Team posted a whitepaper about DNS rebinding attacks in 2007. But even if it’s a well-known type of attacks, nowadays you still can find software systems which are vulnerable to DNS rebinding attacks. For example, Google Project Zero recently discovered such problems in Blizzard Update Agent and BitTorent Transmission Daemon.
I was recently debugging one Python application which ran in a Docker container. At some point, I’d like to debug the app in the container. At first, I was wondering if there is a way to run a Python application with a debug agent like you can do with Java, so that the agent listened in a port for incoming connections from a remote debugger. Unfortunately I didn’t find a convenient way how I could remotely debug my Python app. I found an article which describes how you can debug a Python application remotely with PyCharm IDE and SSH. If I understood correctly, PyCharm can deploy your application to a Docker container via SSH, then do some magic which is called “remote interpreter”, so as a result, you can debug the application from your local PyCharm installation. Looks like this feature is available only in a commercial PyCharm version, but I had only a community edition.
OpenJDK and AddressSanitizer are well-known open source projects. OpenJDK sources contain C/C++ code which may be affected by memory corruption issues and memory leaks. Such issues may be detected at runtime with memory checkers like AddressSanitizer. Now it’s going to be easier to use AddressSanitizer for OpenJDK development to check for memory corruptions and leaks.