Secure Software Blog

Using threat libraries

2017-05-31T00:00:00+02:00

This is a long post. TL;DR: do you approach secure software from the threat perspective or the hardening perspective, and is it really that different?

In the Framework Secure Software, one of the central activities is maintaining a list of threats, mitigations and verifications. Threats can come from different sources:

forgotten or incorrect security requirements
insecure use of technologies, i.e. architectural threats
third party components
coding mistakes

I would like to focus on the second source of threats: insecure use of technologies. Although all the above sources are important and even somewhat related, I think that mitigating architectural threats is where we can win the most.

Because it is technical in nature, developers (and architects) can best tackle this. Unfortunately, most of them have never learned about specific technical security threats or learned how to apply a security mindset to their work.

That does not mean that they are not good developers, it simply means that they have not learned enough about security. How this happened and what we should do about it, could be the topic of another post and I will not focus on that. Besides, because the rapid changes in technology, even if you had thorough security education, you would not know everything unless you constantly keep up-to-date.

Therefore, we have to assume that, in a typical situation, technologies will be used insecurely. For example, the technology itself may not be able to satisfy the system’s security requirements. Or, a technology used in the wrong way could lead to insecure situations. Knowing what can go wrong and such specific threats can be mitigated is key to countering such insecure usage. In the Framework Secure Software, the use of a threat library is advised to identify architectural threats.

In this post, I would like to describe some of my experiences with using such a threat library.

Threat libraries

In the first release of the text of the Framework Secure Software, the specifics of the threat libraries were not discussed, because this was not only still a work in progress, but also because the content of such threat libraries would be highly technology-dependent, and therefore more suited to be described in another document.

I was asked recently to check a software component for security, using the approach of the Framework Secure Software. Because this was an almost finished system, its design was already clear: a HTTP server sending and receiving SAML authentication messages. This choice of technologies defines what threats we can expect: web application threats and threats specific to SAML and its underlying technology: XML signatures and XML.

For the HTTP threats, I chose a subset of the ASVS verification requirements as part of the threat library. For the other technologies, I had to compile a custom threat library.

ASVS

The OWASP ASVS project is a list of “verification requirements”, but I would like to avoid using that term because what is in the list are neither what I would like to call “requirements”, nor “verifications”. I prefer to see it as a list of standard mitigations to counter certain threats. Quoting from the ASVS 3.0.1, it has two main goals:

to help organizations develop and maintain secure applications
to allow security service, security tools vendors, and consumers to align their requirements and offerings

That more or less fit my goals, but the relative completeness of the ASVS standard makes it an excellent basis for a threat library.

Threats for SAML, XML signatures, XML

For SAML, XML signatures and XML threats, there was no authoritative checklist. Therefore I had to compile my own list of threats, based on every known security problem that I could find about these technologies. The result was a list of about 20 threats.

Two approaches to implementing security

There are two ways to approach security (defined in the dictionary as “protection against threats”): look at the threats and implement protections (let’s call this the threat approach); or implement the protections without worrying whether a threat may be applicable (let’s call it the hardening approach).

The reasoning behind the hardening approach is that assessing whether a certain threat is applicable may take some time, while implementing the protection is relatively simple. Therefore, it makes things easier. We see this approach a lot in platform security, in so-called hardening guides. For example, instead of assessing whether the security vulnerability in libnacho.4.1.2 really is applicable, you simply apply the security patch, because that is easier. This approach makes a lot of sense.

That does not mean however that we should not use the threat approach. In cases where there is no standard universal mitigation, which is quite often the case in software, the hardening approach is not really useful. In software, the assumption that the mitigation costs less effort than the threat analysis may also not hold.

The hardening approach in ASVS

ASVS chooses the hardening approach. In my SAML threat library, I chose the threat approach. Let’s compare them. This is information from ASVS:

V2.9: Verify that the changing password functionality includes the old password, the new password, and a password confirmation.

The threat approach in the SAML threat library

In contrast, this is an example threat from my SAML threat library:

XMLSIG: Signature exclusion

Threat: A signature check can be bypassed by omitting the signature completely.

Situation: XML signatures

Suggested Mitigation: Check if the correct signature is present and give an error message if it is not.

Suggested Verification: code review/unit test

Remarks: It should be checked whether the signature is present and if not, processing should be rejected.

References:

[1] Somorovsky, J., Mayer, A., Schwenk, J., Kampmann, M., and Jensen, M. On Breaking SAML: Be Whoever You Want to Be. https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf, retrieved 2016-12-07.

[2] WS-Attacks.org, XML Signature Exclusion. http://ws-attacks.org/XML_Signature_Exclusion, retrieved 2016-12-08.

Which approach is best?

So when should you use which approach? The hardening approach is more efficient in cases where the mitigation is standard and easy. It also takes away the need for thinking about and understanding the threat. The threat approach forces you to think about the threat and to fully understand it, which is needed in cases where the mitigation is not so straightforward. Using a mixture of both would be the ideal approach.

The efficiency of the hardening approach comes at a price. If the underlying assumption about the ease or applicability of the mitigation is not correct, you will need to switch to the threat aproach and need to understand why this mitigation is needed, i.e. against what threat it tries to protect. If it is difficult to get this information, your security suddenly becomes a lot harder. In the ASVS example, if you do not know that the underlying threat is that an attacker can modify your password because he can get control over your browser (via an unlocked screen, or via CSRF techniques), it is difficult to think of alternative mitigations. It is also more difficult to decide whether the underlying risk is acceptable or not.

In the example of the SAML threat, we see much more information. The suggested mitigation is still there, but it is explained why not implementing the mitigation can be a problem. The situation in which this threat is applicable is also given, so that you can determine whether or not you have to mitigate this threat (which is obvious here). More detailed information is given in the references, such as example attacks. In the remarks additional information is given that can point out important implementation details or less ideal, but perhaps acceptable, approaches. The suggested verification gives some advice on how you could best verify if your mitigation is implemented correctly.

You may argue that this does not look too different from some hardening guides out there. In fact, if you look at some of the hardening guides that are made available by the Center for Internet Security (the so-called benchmarks), you will see a structure that is not unlike the structure in my SAML threat library: a description that explains the mitigation, a rationale that explains what the underlying threat is, a section called audit that can be used to verify if the mitigation is correctly implemented, a remediation section explaining in detail how to execute the mitigation, and references containing a more detailed explanation.

In the Apache web server benchmarks, we see that the guides started using this structure in 2010. Earlier guides gave you the mitigation, but without explaining why this was needed. Back then, a security expert would simply know this. But today, security has grown so big that it is impossible for a security expert to remember all details. The rationale section is a great help.

What ASVS can learn from platform security hardening

This is where ASVS can be improved. Some of the “verification requirements” in ASVS puzzle me. Let’s take two examples:

5.18 Verify that client side validation is used as a second line of defense, in addition to server side validation.

Client side validation should never be relied on if the data is to be processed by the server, and because it is so easy to bypass, how could this ever be a realistic line of defense? This is where a rationale could really help, because perhaps there is a situation where client side validation can be used as a second line of defense and where it makes sense to implement it.

19.7 Verify that all application components are signed.

Even when read in its context of application configuration, it is not clear what the underlying threat is. Do components need to be signed so that they can be verified at run-time, to prevent against tampering of binary modules on a system (but in that case, how would you protect against tampering with the tampering detection?), or is it that the component signatures are verified after downloading when installing the software? Without a rationale, this is difficult to say.

Evolution of threat libraries

When technologies are relatively new, no hardening guides are available. The threat based approach makes more sense in that case. As standard mitigations are developed, either within an organization or as common knowledge, we can save a lot of effort by moving to a hardening approach. But moving to a hardening approach makes it more difficult to implement alternative, more efficient approaches, if the underlying threat is not clear.

This is where many organizations are missing the point. Simply giving a hardening guide to developers without them understanding what the underlying threats are will not work. Training can help here, but it would be more effective to include the rationale with each mitigation. If you start from a threat library, it can naturally evolve into a useful hardening guide, because it is effectively the same thing.

The motivation behind the use of a threat library has a great influence here. If compliance is deemed more important than security, it is more likely that the hardening approach is chosen over the threat approach. Be aware that this may lead to a false sense of security, for the reasons described earlier.

Using the threat libraries in practice

With the development team, I had the opportunity to use both ASVS and my SAML library and compare the approaches.

Many of the developers had little secure programming experience, so it was interesting to compare the two threat libraries. In both approaches, developers misinterpreted certain mitigations. For example, if the mitigation said “make sure that the message is signed”, I would get a response that the messages that the application generates are signed, while instead the threat applied to incoming messages for which the signature should be verified. It is very important to phrase your threats and mitigations correctly and not to assume that developers interpret the information in the way that was intended. In the description of the threat, it is better to be very explicit about what actions are taken by whom in the attack scenario.

As expected, for the ASVS threats it was sometimes needed to explain the underlying threat. For the SAML threats, this was also needed, despite the threat description that was included. I blame both the complexity of the threats and unclear threat descriptions for this.

The developers were given the threat libraries without any additional training, which I think would have helped to get better results. Despite that, we managed to show that all threats from the threat libraries were either mitigated, not applicable or accepted. All in all this took only a few short sessions.

The result: the developers can show that they have thought about security, I was able to effectively verify their mitigations in a source code review but perhaps the biggest win by far was that the developers now have a better understanding of security in their specific area of software development.

Ambiguous ANTLR lexer rules

2017-05-31T00:00:00+02:00

In program analysis, parsing is often needed. ANTLR is a great parser generator, but it can be frustrating if your grammar is ambiguous. I have found that lexer ambiguities can cost you quite some time. Here is a little trick that may help.

An example: Graphstream DGS

I was writing a parser for Graphstream DGS (after all, in program analysis, graphs are important too). The formal specification was a bit incomplete and ambiguous, but with some help of the source code I managed to get something working, until I came across the following rules:

fragment HEXBYTE : ([0-9a-fA-F]) ([0-9a-fA-F]) ;
COLOR : '#' HEXBYTE HEXBYTE HEXBYTE HEXBYTE? ;

COMMENT : '#' .*? EOL;

These lexer rules overlap. ANTLR’s ambiguity resolution takes the first alternative, but only if both rules would match the same input. This works as expected if you have for example reserved words:

ENUM : 'enum';
ID: [a-z]+;

For the input enum Categories { ... }, the input enum will be matched by both rules ENUM and ID. However, if the input would contain enumerate(x) then both ENUM and ID will match, but they will match a different part of the input: enum and enumerate. In that case, the longest match wins. This is also what we usually want.

The situation here is similar. For the input color=#ff0000,length=4, both COLOR and COMMENT will match, but on a different input string. In this case, COMMENT will win, and this is not what we want.

The fix: shortening lexer tokens

A trick is to make the COMMENT token shorter than the COLOR token. We can do this by using ANTLR’s lexer modes, which are used for so-called island grammars.

The COMMENT token will be split in two tokens, START_COMMENT and COMMENT. The first is hidden with skip, but it puts the lexer into ‘comment mode’ (CMT). In comment mode, we match everything including the newline into the token COMMENT. To the parser there is still only one token, COMMENT.

START_COMMENT : '#' -> pushMode(CMT), skip;

mode CMT;

COMMENT : .*? EOL -> popMode ;

You cannot use lexer modes in combined grammars, you will need to split your grammar into a lexer grammar and a parser grammar.

About lexer modes

Lexer modes may make things easier or more readable, but sometimes it is better to fix the lexer patterns or create rules in the parser. Too many lexer modes can make one lose the overview, so use them wisely. I prefer to use them only if it makes sense, such as is the case for island grammars. The above hack could have been solved with a parse rule, but it would have cluttered my parse tree. In this case, the trick with lexer modes made more sense.

Fighting Cybercrime

2016-10-04T00:00:00+02:00

When the bike that I parked got stolen a few years ago, I did not report it to the police. Getting your bike stolen is one of those things that just happens to you, at least here in the Netherlands. I was even inclined to say that it was my own fault, because I did not lock it properly. From experience I know that the police cannot do much and reporting the stolen bike is simply too much effort for not getting any results.

Situational prevention

What creates the crime, the criminal or the situation? This is a classic question among criminologists. Due to the fundamental attribution error, we tend to underestimate the role of situational factors for a crime. This however, is wrong, says an article by Ronald V Clarke in the 2016 May-June issue of The Criminologist (found via Bruce Schneier’s blog.) This has consequences for how to prevent crime. Instead of focusing on preventing people to become criminals, it may be more effective to focus more on situational prevention.

Clarke mentions that especially in situations where people did not have high expectations from the authorities, crime was reduced. By making it harder to commit the crime, the opportunity costs where simply too high for the criminal. Good examples are locking your bicycle, city guards, reducing the amount of cash in a store, better lighting etc. Instead of relying on the authorities, a form of self defense was applied. To quote the article:

“It is surely not because these businesses and organizations are trying to make society safer from crime. Rather, it is because experience has taught them they get only limited help from the authorities when they become crime victims. Therefore if they are to become more efficient and reduce their costs they must make themselves less vulnerable to crime. To do so they must make crime more difficult, more risky, less tempting and less rewarding.”

Today’s cybercrime situation is not unlike bike theft, in that little help can be expected from the authorities. In an earlier post, I discussed a report from the Dutch CPB (Bureau for Economic Policy Analysis). It contains an interesting analysis of the causes of software vulnerabilities, but also talks about cybercrime. According to that report,

cybercrime is often not reported, because there is little faith in the legal system to catch the criminals
the probability of getting caught is very low
the penalty is extremely low compared to the profit
cybercriminals are opportunistic, like traditional criminals

If we combine this information with Clarke’s analysis, we could conclude that the most effective solution to the cybercrime problem would be to make the crime less attractive, in other words, to apply “cyber self defense”. However, we do not see many results yet from cyber self defense. It is interesting to ask why that is.

Why is cyber self defense failing?

I can think of four reasons why cyber self defense would not be effective.

The first reason is that the potential victims may not be aware enough of the problem, and therefore do not take appropriate measures. There is a big element of truth in that, but as we see more and more cybercrime stories in the news this lack of awareness is slowly disappearing. Still, more awareness is needed.

Related to that may be the fact that although people are aware of insecure situations, they still behave in an insecure way. Always keeping your guard up takes discipline and costs energy, energy that we would like to spend on more pleasant and productive things. After a while, we tend to be less sharp and accept insecure situations, even though we know we should check things. Failing to check a cryptographic fingerprint, accepting an untrusted server certificate, connecting to unknown WiFi networks, even if the warning is displayed in our face, we sometimes decide to accept the insecure situation. And most of the times, nothing bad happens, which reinforces our belief that things are not so bad and we may just be paranoid. Also here, more awareness certainly helps to keep us disciplined, but wouldn’t a technological solution to the problem be far more effective?

And that is where the security sales persons enter the picture. Just get the right set of products, a firewall, a virus scanner, or even better, an all-in-one solution, and you will not have to worry about security anymore. That is a comforting thought, a bit like having a good bicycle lock. But how do we really know whether these products are effective? Security is, after all, invisible. Security tools are good, but blindly trusting them is not. Ineffective security measures will lead to a false sense of security, which may even be more dangerous than knowing that you are not secure.

So, in the end, should we conclude that we are helpless and simply cannot defend ourselves? I would like to be less grim, but there is a crucial component in the cybercrime story that is our Achilles’ heel: insecure technology. Think of an IT product. How many people are capable of checking the security, and fixing it if it is broken? Now compare that with a refrigerator or washing machine. You cannot simply call a software repair person to check and repair the software that you are running. If you are lucky, you can pay for a software support contract. In theory, open source software would give you the possibility to have it checked and repaired, but it would cost even an expert user too much time to completely check the security of an open source mobile phone operating system, let alone repair it. The choice is to accept security bugs and hope that they never affect you, or spend a lot of time or money to get a secure alternative. Of course, there are exceptions, and many people do try to fix security problems in open source software, but still not enough. We are too dependent on something over which we have little control.

What can the authorities do?

Perhaps the last point is where the authorities can really help, by somehow reducing the number of security problems in the software products that we buy. Several possibilities exist, ranging from liability to a stamp of approval. The earlier mentioned CPB report discusses these. To protect consumers they suggest to make the provider of the software or service liable for at least a certain amount or force them to ensure a minimum level of security. As a consumer, I would be happy with such a law, but I would not be working in security if I did not see a few difficulties.

TP3 Gremlin repeat/emit/select strangeness

2016-09-15T00:00:00+02:00

Say, you would like to traverse a function’s AST tree and for every tree node, you would like to find the identifiers and print a message “node has identifier id”.

Let’s take a simple function:

void aexp_test_1 ()
{
	x = 8 * ++a - b;
}

The traversal we have in mind is given an AST node, traverse the child nodes, and for each childnode, traverse its childnodes that are identifiers and select both the node and the identifier. Ok, this may not be the most efficient algorithm, but let’s not worry about optimizations for now.

Let’s take this step by step. First we need an AST node:

g.V()
.has('type','Function')
.has('code','aexp_test_1')
.functionToAST()

Then we need its AST nodes:

.astNodes()

Each of these AST nodes needs to be labeled for later use in a select step:

.as('astnode')

Next, we need to traverse its children, but we are only interested in the identifier nodes, which we will label with identifier:

.repeat(out(AST_EDGE)).emit{ it.get().value('type') == 'Identifier' }
.as('identifier')

Then, we select both, and we are interested in the code property:

.select('astnode','identifier')
.by('code')

We run the traversal, but we get an error message:

java.lang.ClassCastException

Something is not right! When a traversal does not work, I try to comment out steps from the end until the traversal works. In this case, it is the by step that causes problems. Let’s look at the output from the select step:

{

'identifier':

	{'id': 12336, 'type': 'vertex', 'properties': {'_key': [{'id': '746-9io-sl', 'value': '58'}], 'type': [{'id': '7ie-9io-1l1', 'value': 'Identifier'}], 'location': [{'id': '8au-9io-27t1', 'value': ''}], 'isCFGNode': [{'id': '9hi-9io-2a6d', 'value': ''}], 'code': [{'id': '7wm-9io-3yd', 'value': 'a'}], 'functionId': [{'id': '8p2-9io-28lh', 'value': '47'}], 'childNum': [{'id': '93a-9io-29dx', 'value': '1'}]}, 'label': 'vertex'},

'astnode':

	[{'id': 49344, 'type': 'vertex', 'properties': {'_key': [{'id': 'zko-122o-sl', 'value': '49'}], 'type': [{'id': 'zyw-122o-1l1', 'value': 'CompoundStatement'}], 'location': [{'id': '10rc-122o-27t1', 'value': '12:0:111:131'}], 'isCFGNode': [{'id': '11y0-122o-2a6d', 'value': ''}], 'code': [{'id': '10d4-122o-3yd', 'value': ''}], 'functionId': [{'id': '115k-122o-28lh', 'value': '47'}], 'childNum': [{'id': '11js-122o-29dx', 'value': '0'}]}, 'label': 'vertex'},
	{'id': 8240, 'type': 'vertex', 'properties': {'_key': [{'id': '3ye-6cw-sl', 'value': '50'}], 'type': [{'id': '4cm-6cw-1l1', 'value': 'ExpressionStatement'}], 'location': [{'id': '552-6cw-27t1', 'value': '13:1:114:129'}], 'isCFGNode': [{'id': '6bq-6cw-2a6d', 'value': 'True'}], 'code': [{'id': '4qu-6cw-3yd', 'value': 'x = 8 * ++ a - b'}], 'functionId': [{'id': '5ja-6cw-28lh', 'value': '47'}], 'childNum': [{'id': '5xi-6cw-29dx', 'value': '0'}]}, 'label': 'vertex'},
	{'id': 53440, 'type': 'vertex', 'properties': {'_key': [{'id': '12qg-158g-sl', 'value': '51'}], 'type': [{'id': '134o-158g-1l1', 'value': 'AssignmentExpression'}], 'location': [{'id': '13x4-158g-27t1', 'value': ''}], 'isCFGNode': [{'id': '153s-158g-2a6d', 'value': ''}], 'code': [{'id': '13iw-158g-3yd', 'value': 'x = 8 * ++ a - b'}], 'functionId': [{'id': '14bc-158g-28lh', 'value': '47'}], 'childNum': [{'id': '14pk-158g-29dx', 'value': '0'}]}, 'label': 'vertex'},
	{'id': 61632, 'type': 'vertex', 'properties': {'_key': [{'id': '1920-1bk0-sl', 'value': '53'}], 'type': [{'id': '19g8-1bk0-1l1', 'value': 'AdditiveExpression'}], 'location': [{'id': '1a8o-1bk0-27t1', 'value': ''}], 'isCFGNode': [{'id': '1bfc-1bk0-2a6d', 'value': ''}], 'code': [{'id': '19ug-1bk0-3yd', 'value': '8 * ++ a - b'}], 'functionId': [{'id': '1amw-1bk0-28lh', 'value': '47'}], 'childNum': [{'id': '1b14-1bk0-29dx', 'value': '1'}]}, 'label': 'vertex'}
]
}

Now that is strange, we did not expect astnode to be a list. After some experimenting, it turned out to have something to do with emit. We have used emit twice in the traversal (one is hidden in astNodes()).

Let’s investigate and take a simpler traversal. We take the root AST node, label it rootnode and traverse all its AST children, which will get the label node.

g.V()
.has('type','Function')
.has('code','aexp_test_1')
.functionToAST()
.as('rootnode')
.repeat(out(AST_EDGE)).emit()  // get AST nodes
.as('node')
.select('rootnode','node')

The first result looks like:

{
	'rootnode':
		{'id': 32992, 'properties': {'isCFGNode': [{'value': '', 'id': 'pb0-pgg-2a6d'}], 'type': [{'value': 'FunctionDef', 'id': 'nbw-pgg-1l1'}], 'childNum': [{'value': '0', 'id': 'ows-pgg-29dx'}], 'functionId': [{'value': '47', 'id': 'oik-pgg-28lh'}], 'code': [{'value': 'aexp_test_1 ()', 'id': 'nq4-pgg-3yd'}], 'location': [{'value': '', 'id': 'o4c-pgg-27t1'}], '_key': [{'value': '48', 'id': 'mxo-pgg-sl'}]}, 'type': 'vertex', 'label': 'vertex'},
	'node':
		{'id': 16432, 'properties': {'isCFGNode': [{'value': '', 'id': 'cna-cog-2a6d'}], 'type': [{'value': 'ReturnType', 'id': 'ao6-cog-1l1'}], 'childNum': [{'value': '1', 'id': 'c92-cog-29dx'}], 'functionId': [{'value': '47', 'id': 'buu-cog-28lh'}], 'code': [{'value': 'void', 'id': 'b2e-cog-3yd'}], 'location': [{'value': '', 'id': 'bgm-cog-27t1'}], '_key': [{'value': '60', 'id': 'a9y-cog-sl'}]}, 'type': 'vertex', 'label': 'vertex'}
}

But in the last result, node is a list:

{
	'rootnode':
	{'id': 32992, 'properties': {'isCFGNode': [{'value': '', 'id': 'pb0-pgg-2a6d'}], 'type': [{'value': 'FunctionDef', 'id': 'nbw-pgg-1l1'}], 'childNum': [{'value': '0', 'id': 'ows-pgg-29dx'}], 'functionId': [{'value': '47', 'id': 'oik-pgg-28lh'}], 'code': [{'value': 'aexp_test_1 ()', 'id': 'nq4-pgg-3yd'}], 'location': [{'value': '', 'id': 'o4c-pgg-27t1'}], '_key': [{'value': '48', 'id': 'mxo-pgg-sl'}]}, 'type': 'vertex', 'label': 'vertex'},

	'node':
	[
		{'id': 49344, 'properties': {'isCFGNode': [{'value': '', 'id': '11y0-122o-2a6d'}], 'type': [{'value': 'CompoundStatement', 'id': 'zyw-122o-1l1'}], 'childNum': [{'value': '0', 'id': '11js-122o-29dx'}], 'functionId': [{'value': '47', 'id': '115k-122o-28lh'}], 'code': [{'value': '', 'id': '10d4-122o-3yd'}], 'location': [{'value': '12:0:111:131', 'id': '10rc-122o-27t1'}], '_key': [{'value': '49', 'id': 'zko-122o-sl'}]}, 'type': 'vertex', 'label': 'vertex'},
		{'id': 8240, 'properties': {'isCFGNode': [{'value': 'True', 'id': '6bq-6cw-2a6d'}], 'type': [{'value': 'ExpressionStatement', 'id': '4cm-6cw-1l1'}], 'childNum': [{'value': '0', 'id': '5xi-6cw-29dx'}], 'functionId': [{'value': '47', 'id': '5ja-6cw-28lh'}], 'code': [{'value': 'x = 8 * ++ a - b', 'id': '4qu-6cw-3yd'}], 'location': [{'value': '13:1:114:129', 'id': '552-6cw-27t1'}], '_key': [{'value': '50', 'id': '3ye-6cw-sl'}]}, 'type': 'vertex', 'label': 'vertex'},
		{'id': 53440, 'properties': {'isCFGNode': [{'value': '', 'id': '153s-158g-2a6d'}], 'type': [{'value': 'AssignmentExpression', 'id': '134o-158g-1l1'}], 'childNum': [{'value': '0', 'id': '14pk-158g-29dx'}], 'functionId': [{'value': '47', 'id': '14bc-158g-28lh'}], 'code': [{'value': 'x = 8 * ++ a - b', 'id': '13iw-158g-3yd'}], 'location': [{'value': '', 'id': '13x4-158g-27t1'}], '_key': [{'value': '51', 'id': '12qg-158g-sl'}]}, 'type': 'vertex', 'label': 'vertex'},
		{'id': 61632, 'properties': {'isCFGNode': [{'value': '', 'id': '1bfc-1bk0-2a6d'}], 'type': [{'value': 'AdditiveExpression', 'id': '19g8-1bk0-1l1'}], 'childNum': [{'value': '1', 'id': '1b14-1bk0-29dx'}], 'functionId': [{'value': '47', 'id': '1amw-1bk0-28lh'}], 'code': [{'value': '8 * ++ a - b', 'id': '19ug-1bk0-3yd'}], 'location': [{'value': '', 'id': '1a8o-1bk0-27t1'}], '_key': [{'value': '53', 'id': '1920-1bk0-sl'}]}, 'type': 'vertex', 'label': 'vertex'},
		{'id': 65728, 'properties': {'isCFGNode': [{'value': '', 'id': '1el4-1eps-2a6d'}], 'type': [{'value': 'MultiplicativeExpression', 'id': '1cm0-1eps-1l1'}], 'childNum': [{'value': '0', 'id': '1e6w-1eps-29dx'}], 'functionId': [{'value': '47', 'id': '1dso-1eps-28lh'}], 'code': [{'value': '8 * ++ a', 'id': '1d08-1eps-3yd'}], 'location': [{'value': '', 'id': '1deg-1eps-27t1'}], '_key': [{'value': '54', 'id': '1c7s-1eps-sl'}]}, 'type': 'vertex', 'label': 'vertex'},
		{'id': 24816, 'properties': {'isCFGNode': [{'value': '', 'id': 'izi-j5c-2a6d'}], 'type': [{'value': 'UnaryExpression', 'id': 'h0e-j5c-1l1'}], 'childNum': [{'value': '1', 'id': 'ila-j5c-29dx'}], 'functionId': [{'value': '47', 'id': 'i72-j5c-28lh'}], 'code': [{'value': '++ a', 'id': 'hem-j5c-3yd'}], 'location': [{'value': '', 'id': 'hsu-j5c-27t1'}], '_key': [{'value': '56', 'id': 'gm6-j5c-sl'}]}, 'type': 'vertex', 'label': 'vertex'},
		{'id': 20616, 'properties': {'isCFGNode': [{'value': '', 'id': 'ftd-fwo-2a6d'}], 'type': [{'value': 'IncDec', 'id': 'du9-fwo-1l1'}], 'childNum': [{'value': '0', 'id': 'ff5-fwo-29dx'}], 'functionId': [{'value': '47', 'id': 'f0x-fwo-28lh'}], 'code': [{'value': '++', 'id': 'e8h-fwo-3yd'}], 'location': [{'value': '', 'id': 'emp-fwo-27t1'}], '_key': [{'value': '57', 'id': 'dg1-fwo-sl'}]}, 'type': 'vertex', 'label': 'vertex'}
	]
}

???

In short: if we use emit normally, we will see only the element that was emitted, but as soon as we start to label it for use with select, a list of elements is stored.

The Gremlin documentation does not tell what is emitted, but it tells us that emit splits the traverser in two. This could explain the observed behaviour.

My hypothesis (or wild guess) is that emit creates a subtraversal that normally is traversed, but when labeled with as, not the elements in that traversal that are labeled, but the traversal itself. Or something like that.

A solution could be to unfold the subtraversal. Let’s see how that works:

g.V()
.has('type','Function')
.has('code','aexp_test_1')
.functionToAST()
.as('rootnode')
.repeat(out(AST_EDGE)).emit().unfold()  // get AST nodes
.as('node')
.select('rootnode','node')

Now the last node is no longer a list:

{
	'rootnode':
		{'type': 'vertex', 'label': 'vertex', 'id': 32992, 'properties': {'functionId': [{'id': 'oik-pgg-28lh', 'value': '47'}], 'code': [{'id': 'nq4-pgg-3yd', 'value': 'aexp_test_1 ()'}], 'isCFGNode': [{'id': 'pb0-pgg-2a6d', 'value': ''}], 'location': [{'id': 'o4c-pgg-27t1', 'value': ''}], 'type': [{'id': 'nbw-pgg-1l1', 'value': 'FunctionDef'}], '_key': [{'id': 'mxo-pgg-sl', 'value': '48'}], 'childNum': [{'id': 'ows-pgg-29dx', 'value': '0'}]}},
	'node':
		{'type': 'vertex', 'label': 'vertex', 'id': 20616, 'properties': {'functionId': [{'id': 'f0x-fwo-28lh', 'value': '47'}], 'code': [{'id': 'e8h-fwo-3yd', 'value': '++'}], 'isCFGNode': [{'id': 'ftd-fwo-2a6d', 'value': ''}], 'location': [{'id': 'emp-fwo-27t1', 'value': ''}], 'type': [{'id': 'du9-fwo-1l1', 'value': 'IncDec'}], '_key': [{'id': 'dg1-fwo-sl', 'value': '57'}], 'childNum': [{'id': 'ff5-fwo-29dx', 'value': '0'}]}}
}

Let’s try this in our original query:

g.V()
.has('type','Function')
.has('code','aexp_test_1')
.functionToAST()
.astNodes().unfold()
.as('astnode')
.repeat(out(AST_EDGE)).emit{ it.get().value('type') == 'Identifier' }.unfold()
.as('identifier')
.select('astnode','identifier')
.by('code')

The result:

{'identifier': 'x', 'astnode': ''}
{'identifier': 'b', 'astnode': ''}
{'identifier': 'a', 'astnode': ''}
{'identifier': 'x', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'b', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'a', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'x', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'b', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'a', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'b', 'astnode': '8 * ++ a - b'}
{'identifier': 'a', 'astnode': '8 * ++ a - b'}
{'identifier': 'a', 'astnode': '8 * ++ a'}
{'identifier': 'a', 'astnode': '++ a'}

It turns out that using only the first unfold is sufficient, but an extra unfold does not hurt.

It looks like it worked, but why do we not see the identifiers in the ast nodes? That is because the second traversal tries to traverse AST_EDGE edges. If that does not work, the traversal will not yield any results. If you also want to emit the elements from which no traversal can be made, you need to emit before the repeat:

g.V()
.has('type','Function')
.has('code','aexp_test_1')
.functionToAST()
.astNodes().unfold()
.as('astnode')
.emit{ it.get().value('type') == 'Identifier' }
.repeat(out(AST_EDGE))
.unfold()
.as('identifier')
.select('astnode','identifier')
.by('code')

which results in:

{'astnode': '', 'identifier': 'x'}
{'astnode': '', 'identifier': 'b'}
{'astnode': '', 'identifier': 'a'}
{'astnode': 'aexp_test_1', 'identifier': 'aexp_test_1'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'x'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'b'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'a'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'x'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'b'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'a'}
{'astnode': 'x', 'identifier': 'x'}
{'astnode': '8 * ++ a - b', 'identifier': 'b'}
{'astnode': '8 * ++ a - b', 'identifier': 'a'}
{'astnode': '8 * ++ a', 'identifier': 'a'}
{'astnode': 'b', 'identifier': 'b'}
{'astnode': '++ a', 'identifier': 'a'}
{'astnode': 'a', 'identifier': 'a'}

Strictly speaking, this should also happen in astNodes:

GraphTraversal.metaClass.astNodes = {
	delegate.repeat(__.start().children()).until(noMoreChildren()).emit{true}
}

So, let’s inline the other implementation for now:

g.V()
.has('type','Function')
.has('code','aexp_test_1')
.functionToAST()
.emit().repeat(out(AST_EDGE)).unfold()
.as('astnode')
.emit{ it.get().value('type') == 'Identifier' }
.repeat(out(AST_EDGE))
.unfold()
.as('identifier')
.select('astnode','identifier')
.by('code')

The results still contains duplicates, but all AST nodes are included!

{'identifier': 'aexp_test_1', 'astnode': 'aexp_test_1 ()'}
{'identifier': 'x', 'astnode': 'aexp_test_1 ()'}
{'identifier': 'b', 'astnode': 'aexp_test_1 ()'}
{'identifier': 'a', 'astnode': 'aexp_test_1 ()'}
{'identifier': 'x', 'astnode': ''}
{'identifier': 'b', 'astnode': ''}
{'identifier': 'a', 'astnode': ''}
{'identifier': 'aexp_test_1', 'astnode': 'aexp_test_1'}
{'identifier': 'x', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'b', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'a', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'x', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'b', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'a', 'astnode': 'x = 8 * ++ a - b'}
{'identifier': 'x', 'astnode': 'x'}
{'identifier': 'b', 'astnode': '8 * ++ a - b'}
{'identifier': 'a', 'astnode': '8 * ++ a - b'}
{'identifier': 'a', 'astnode': '8 * ++ a'}
{'identifier': 'b', 'astnode': 'b'}
{'identifier': 'a', 'astnode': '++ a'}
{'identifier': 'a', 'astnode': 'a'}

To eliminate the duplicates, we insert a dedup step at the end. The query becomes:

g.V()
.has('type','Function')
.has('code','aexp_test_1')
.functionToAST()
.emit().repeat(out(AST_EDGE)).unfold()
.as('astnode')
.emit{ it.get().value('type') == 'Identifier' }
.repeat(out(AST_EDGE))
.unfold()
.as('identifier')
.select('astnode','identifier')
.by('code')
.dedup()

{'astnode': 'aexp_test_1 ()', 'identifier': 'aexp_test_1'}
{'astnode': 'aexp_test_1 ()', 'identifier': 'x'}
{'astnode': 'aexp_test_1 ()', 'identifier': 'b'}
{'astnode': 'aexp_test_1 ()', 'identifier': 'a'}
{'astnode': '', 'identifier': 'x'}
{'astnode': '', 'identifier': 'b'}
{'astnode': '', 'identifier': 'a'}
{'astnode': 'aexp_test_1', 'identifier': 'aexp_test_1'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'x'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'b'}
{'astnode': 'x = 8 * ++ a - b', 'identifier': 'a'}
{'astnode': 'x', 'identifier': 'x'}
{'astnode': '8 * ++ a - b', 'identifier': 'b'}
{'astnode': '8 * ++ a - b', 'identifier': 'a'}
{'astnode': '8 * ++ a', 'identifier': 'a'}
{'astnode': 'b', 'identifier': 'b'}
{'astnode': '++ a', 'identifier': 'a'}
{'astnode': 'a', 'identifier': 'a'}

Plans for Software Liability

2016-09-14T00:00:00+02:00

On July 6, 2016, the Dutch CPB (Bureau for Economic Policy Analysis) published a report. It describes the economic situation of various aspects of cybercrime, which resembles what is written in the 2008 Geekonomics book by David Rice. Rice’s book is not mentioned as a reference, but it is interesting to see that some of the same conclusions end up in government publications after 8 years.

“Make software vendors liable”

One of the advices is to make the software industry liable for software bugs. Security.nl posted about this. However, it is unfortunate that their article seems to link the liability advice with the types of cybercrime that are precisely not directly caused by software bugs, but mostly by human behaviour, such as ransomware and phishing. This only creates more confusion in the already confusing discussions that I sometimes see. How can one ever hold a supplier liable for the fact that a user clicked on a dangerous link in an email? And which software supplier would be liable in this case? The one supplying the email client software? The OS? Or perhaps the one that supplied the provider’s mail server software?

Ofcourse, as with most security discussions, this discussion is not new: see here, here, here, here, here, and here for just a few examples.

When interpreting these texts however, it is important to keep in mind against which background they were written. Technology has changed, and so has the impact of software vulnerabilities on society. And when having these discussions, it is important to clearly understand the problem, not in the least the technical side of it.

Other options

Software liability only works for problems that are caused by faulty software, as is clear from the report. Rice’s book discusses other directions in which policy can be changed, such as programmer education and certification (either of software vendors or of the products themselves). Unfortunately, the CPB report only spent two sentences on this. It is not discussing programmer education at all, but mentions transparency about software quality as a means to get more control over the failing market situation. Usually, certification is a much more industry friendly and cheaper way than liability, because in the latter case, only lawyers will benefit. But that is not in the report. So let’s elaborate on that and compare liability and certification a little bit.

We need a standard to define “secure”

In order to judge a liability case, it needs to be determined if the accused party is really at fault, for example by being negligent. Did the accused party neglect to take certain security measures that could be expected to be in the software? To answer this, there needs to be a certain standard to compare their software to. Without such a standard, we will get endless discussions about whether the application should have prevented the user from choosing an easy to guess password or not.

The Secure Software Foundation (which is also mentioned in the report) has developed the Framework Secure Software, which can serve as such a standard.

Reactive or proactive?

Another problem of the liability route is that it is a reactive approach. Action is only taken after things have gone wrong. Surely there will be a scare effect that will incentivize suppliers to make more secure software, but again, without a trusted standard, this will be limited to fear only. You may end up paying more for an equally bad product, only because the vendor needs a bigger war chest for legal battles.

Then there is the big question whether open source software suppliers can be held liable. If that is the case, then the whole open source software infrastructure may collapse.

And what about third party software components that are used in software? Does this mean that an accused party may need to accuse one of their suppliers and spend even more on legal battles?

Becoming a software lawyer begins to sound more and more like an excellent career choice: highly in demand, guaranteed pay and more than enough vagueness to give you all the job security you want.

A secure software certificate on the other hand will perform a similar security assessment, but before software is shipped. You will also pay more for your software, but get a better product in return. Open source software developers do not have to worry. If an open source product needs to be independently assessed, it can be done by whoever is willing to spend resources on that. Sounds like a much more productive way to spend money. And remember, you can only spend your money once.

Ending the information asymmetry

Whether you prefer certification or liability as a policy, in either case you need a trusted standard that describes what security aspects can be expected for a certain piece of software.

The report describes that within the software industry, information asymmetry, both for software users and software development organizations, is a cause for market failure. No matter how you want to incentivize the software market to make more secure software, making security visible is the key.