During the end of august I made an audit to the C modules in the popular Python library, version 2.7.12. This audit quickly produced the 1st vulnerability I found in a high-profile library, the 1st of many more that came afterwards.
As was promised in the last posts, today we will discuss the development risks in the (de)fragmentation feature. From a security stand-point this is a Zero-Sum Game: a developer’s nightmare is a researcher’s goldmine, and defragmentation is a goldmine that seems to always payoff.
As I promised in my previous post, here is an official public disclosure of CVE 2016-8633: linux kernel firewire driver remote code execution. The official fix was merged yesterday into the linux kernel, and so I can know talk freely about it.
During last August I made a security audit to an interesting embedded library I have found in Github: libcsp:
Cubesat Space Protocol – A small network-layer delivery protocol designed for Cubesats
This blog post will describe my findings, CVE 2016-8596, CVE 2016-8597, CVE 2016-8598, will publicly disclose the vulnerabilities and will elaborate on the lessons that can be learned from them.
In my master thesis I studied the security aspects of the IEEE 1588 protocol: Precision Time Protocol (PTP). What started as a threat analysis soon became a threat analysis, attack demonstrations and a suggestion for a complete security solution for the protocol. The short version of the article was presented in the ISPCS 2016 conference, and the full version can be found here.
What I found unique about my research wasn’t it’s results, although we did present several new vulnerabilities and proposed mitigations. The unique aspects were actually our method of research, as will be detailed explained in this post. The following chapters will summarize the research plan used in my thesis, alongside several examples for of the advantages it gained us, and the pitfalls we missed because of it. It is highly recommended to read the full article in order to better understand the next chapters.
Regular expressions, or regex, are patterns used commonly for string matching. Although there are several flavors for the regex syntax, the basic building blocks of the pattern language stay roughly the same. While the use of regex for string matching is wide spread, it’s somewhat complicated syntax earned it several jokes, as in this xkcd, or in a comment I recently heard saying that “regex are write-only”, and are tough to read.
What most people don’t know is that the use of regex patterns, that are usually deployed on large input strings, can be sometimes vulnerable to regex Denial of Service (REDoS). A detailed example can be found in the postmortem report about the Stack Exchange outage from last July.
The C/C++ programing language seems simple and quite straight forward to most common/embedded developers. Unfortunately, most of the programmers lack knowledge of the C standard, resulting in many security vulnerabilities that can be found in those dark shadows of the code. This post will try to introduce a small part of the integer overflow world, and specifically it’s sometimes undefined behavior.