When Results Are All That Matters: Consequences

by Andreas Zeller and Sascha Just; with Kai Greshake

The Case

In our previous post "When Results Are All That Matters: The Case of the Angora Fuzzer", we reported our findings when investigating the Angora fuzzer [1]. If you have not read that post yet, you should stop here and read our write-up first. There, we focus on our findings and problems that surprised us when experimenting with Angora.
In this article, we have collected some suggestions to advance the field of fuzzing and have a long-term impact on the reliability of software.

1. Science is about insights, not products.

To ensure scientific progress, we need to know which technique works, how, and under which circumstances. We write papers to document such insights such that the next generation of researchers, as well as the non-scientific world, can build on them.  The value of a paper comes from the impact of its insights.

2. Scientists and companies can create tools.

It is fun to build a tool, and if it works well, the better.  Typically, this will involve not one single magical technique, but a multitude of techniques working together.  Tools will have to succeed on the market, though, and will be evaluated not based on their insights, but their effectiveness.

Evaluating tools for their effectiveness can be part of a scientific approach. However, evaluation settings should

1. be fair and thus not be defined by tool authors; and
2. avoid overspecialization and thus involve tests not previously known to tool authors.

In other words, the only way to obtain reliable performance comparisons is by independent assessment.   Other communities do this through specific tool contests that operate on secret benchmarks created for this very purpose.  And of course, tools need to be available for evaluation in the first place. It is nice to see the security community to adapt such techniques, such as artifact evaluation.

3. Combinations of techniques must be assessed individually.

If results depend on a larger set of novel processing steps, the contribution of each must be – for instance, by replacing each processing step by a naive approach and assessing the impact of the change.  All decisions affecting performance must be well motivated and documented.

Without assessing the impact of each step individually, one can still have a great tool, but the insight on what makes it great will be very limited.  As an analogy: We know that Usain Bolt is a record shattering sprinter; the scientific insight is to find out why.

4. Document your hypotheses, experiments, and results.

Good scientific practice mandates that experiments and their results be carefully documented.  This helps others (but also yourself!) in assessing and understanding the decisions in the course of your project.  If you make some design decision, such as a parameter setting, after examining how your software runs on some example, it is important that the motivation for this design decision can be traced back to the experiment and its result.

If this sounds like lot of work, that's because it is.  We're talking about the scientific method, not some fiddling around with parameters until we reach the desired result on a benchmark.  Fortunately, there are great means to help you with these tasks.  Jupyter Notebooks [8], for instance, allow you to collect your hypotheses (in natural language), your experiment design, its results (in beautiful and interactive graphs, among others), and your next refinement step – allowing anyone (as well as yourself) to understand how a specific result came to be.  Be sure to place your notebooks (and code) under version control from day one, and throw in some tests and assertions for quality assurance.  Control your environment carefully to make results reproducible for anyone.

5. Having benchmarks to compare tools and approaches is helpful, but brings risks.

Benchmarks are helpful means to assess the performance of tools.  However, they bring two risks.

1. First, there is the risk of having researchers focus on the benchmark rather than insights.  It is nice to have a well-performing tool, but its scientific value comes from the insights that make its performance.
2. Second, benchmarks bring the risk of researchers knowingly or unknowingly optimizing their tools for this very benchmark. We have seen this with compilers, databases, mobile phones, fault localization, machine learning, and now fuzzing.  To mitigate the risk of overspecialization, tool performance should be compared on programs they have not seen before.

A benchmark like LAVA-M is representative for detecting buffer overflows during input processing but very little else.  As the LAVA creators state themselves, "LAVA currently injects only buffer overflows into programs" and "A significant chunk of future work for LAVA involves making the generated corpora look more like the bugs that are found in real programs." [3].

It has been shown that optimizing against the artificial LAVA bugs, such as 4-byte string triggers, can have very naive approaches yield impressive results [2].  The conceptual match between the features injected by LAVA and those features exploited by fuzzers such as Angora is striking.

The question of what makes a good benchmark for fuzzers and test generation is still open.  One possible alternative to LAVA-M is Google's fuzzing test suite which contains a diverse set of programs with real bugs [5].  Michael Hicks has compiled excellent guidelines on how to evaluate fuzzers [4, 6].

6. Researchers must resist the temptation of optimizing their tools towards a specific benchmark.

While developing an approach, it is only natural to try it out on some examples to assess its performance, such that results may guide further refinement. The risk of such guidance, however, is that development may result in overspecialization – i.e., an approach that works well on a benchmark, but not on other programs.  As a result, one will get a paper without impact and a tool that nobody uses.

Every choice during implementation has to be questioned "Will this solve a general problem that goes way beyond my example?", and one should take that choice only with a positive, well-motivated answer, possibly involving other experts who would be asked in the abstract.  We recommend that during implementation, only a very small set of examples should be used for guidance; the evaluation should later be run on the full benchmark.

Good scientific practice mandates to create a research and evaluation plan with a clear hypothesis well before the evaluation, and possibly even before the implementation.  This helps to avoid being too biased towards one's own approach. Note that the point of the evaluation is not to show that an approach works, but to precisely identify the circumstances under which it works and the circumstances under which it does not work.

Papers should investigate those situations and clearly report them. Again, papers are about insights, not competition.

7. It is nice to have tools discovering vulnerabilities...

...especially as these vulnerabilities have a value on their own. However, vulnerabilities do not follow statistical distribution rules (hint: otherwise it would be easier to find them).  Having a tool find a number of vulnerabilities in a program, therefore, is not necessarily a good predictor to find bugs in another program.

In any case, the process through which vulnerabilities were found must be carefully documented and made fully reproducible; for random-driven approaches such as fuzzers, one thus needs to log and report random seeds.  Obviously, one must be clear not to optimize tools towards given vulnerabilities.

For fuzzing tools, the technical challenge is to find inputs that cover a wide range of behavior across the program and not only during input processing and error handling.  Let us remind you that during testing, executing a location is a necessary condition for finding a bug in that very location.  Since we are still far from reaching satisfying results in covering functionality, improvements in code coverage are important achievements regardless of bugs being found.

8. What does this mean for reviewers and authors?

Papers must clearly show how the insights of the paper contribute to the result, both in terms of motivation as well as in evaluation.

In many cases, it will be hard to describe all the details of all the necessary steps in the paper. Therefore, it will be necessary to supply an artifact that allows for not only reproduction but also applying it on subjects not seen before; again, all design decisions in the code must be motivated and documented. This is tedious; this is rigorous; this is how science works.

Reviewers should be aware that an approach is not simply "better" because it performs well on a benchmark or because it found new bugs.  Approaches have a long-term impact not only through performance, but also through innovation, generality, and simplicity. Researchers are selected as reviewers because the community trusts them to assess such qualities. Tool performance that is achieved through whatever means has little scientific value.

Having said that, conference organizers should create forums for tool builders and tool users to discuss lessons learned.  Such exchanges can be extremely fruitful for scientific progress, even if they may not be subject to rigorous scientific assessment.  Tool contests with clear and fair rules would allow assessing the benefits and fallbacks of current approaches, and again to foster and guide discussions on where the field should be going.  A contest like Rode0day [7] could serve as a starting point.

Conclusion

Having tools is good, and having tools that solve problems is even better.  As scientists, however, we also must understand why what works and what does not.  As tools and vulnerabilities come and go, it is these insights that have the longest impact.  Our papers, our code and our processes, therefore, must all be shaped to produce, enable, assess, and welcome such insights.  This is the long-term path of how we as scientists can help to make software more reliable and more secure.

Acknowledgments.  Marcel Böhme, Cas Cremers, Thorsten Holz, Mathias Payer, and Ben Stock provided helpful feedback on earlier revisions of this post.  Thanks a lot!

References

[1] P. Chen and H. Chen, "Angora: Efficient Fuzzing by Principled Search." 2018 IEEE Symposium on Security and Privacy (IEEE S&P), San Francisco, CA, 2018, pp. 711-725.
[2] Of bugs and baselines
[3] B. Dolan-Gavitt et al., "LAVA: Large-Scale Automated Vulnerability Addition," 2016 IEEE Symposium on Security and Privacy (S&P), San Jose, CA, 2016, pp. 110-121.
[4] George Klees, Andrew Ruef, Benji Cooper, Shiyi Wei, and Michael Hicks. 2018. Evaluating Fuzz Testing. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18). ACM, New York, NY, USA, 2123-2138.
[5] Google's fuzzing test suite
[6] Michael Hicks, Evaluating Empirical Evaluations (for Fuzz Testing
[7] Rode0day
[8] Project Jupyter

When Results Are All That Matters: The Case of the Angora Fuzzer

by Andreas Zeller and Sascha Just; with Kai Greshake

The Case

"Fuzzers" are programs that generate random inputs to trigger failures in tested programs. They are easily deployed and have found numerous vulnerabilities in various programs. The last decade has seen a tremendous increase in fuzzing research [4].

In 2018, Chen and Chen published the paper "Angora: Efficient Fuzzing by Principled Search" [1] featuring a new gray box, mutation-based fuzzer called Angora. Angora presented extraordinary results in its effectiveness and shines with its stellar performance on the Lava-M benchmark [3], dramatically outperforming all competition.

The reason behind this breakthrough and leap in effectiveness towards deeper penetration of target programs was cited as the combination of four techniques: scalable byte-level taint tracking, context-sensitive branch count, input length exploration, and search based on gradient descent. The former three techniques had already been explored in earlier work; but the novel key contribution, as also indicated by the paper title, was the Gradient Descent approach to solve constraints modeling branch conditions as functions and approximating their gradient.

One of our students was intrigued by the outstanding performance and wanted to investigate why and how optimization strategies affect the fuzzing performance that much - with the initial goal of actually further improving on Angora. To properly measure the effect of his work, he went and worked directly on the Angora source code. During his study [2], he came across some confusing findings, which we summarize below.

The Findings

Angora's Gradient Descent performs similar to Random Search on LAVA-M

Contrary to what is stated in the Angora paper, we could not find real differences between using a random search algorithm and using Gradient descent to solve constraints. After further investigation, it turns out that in almost all optimization cycles, the constraint is solved immediately when the first input is executed. That first input is generated by using magic byte extraction – and only when it is replaced by a random starting point does the performance of Random Search drop off. Since 32-bit magic byte values comprise all of the bugs artificially injected into the LAVA benchmark, it does not surprise that this feature dominates the performance instead of Gradient Descent.

Of course, this raises the question of why Angora is so successful. Magic byte extraction is not a new technique, but in the case of this benchmark, in combination with taint tracking, good heuristics, and other improvements it leads to spectacular results on LAVA-M. However, Gradient Descent contributed little to that success.

These findings are confirmed by Angora's authors [5]: "If the fuzzer can extract the magic bytes and copy them to the correct location in the input, then obviously the fuzzer can solve the constraint immediately." They point out that Gradient Descent will show and did show advantages outside of solving magic byte constraints, even if this is not their evaluation setting. And indeed, our findings do not imply that Gradient Descent would not work; on the contrary, we still find it a highly promising idea. However, whether and when it can make a difference is an open question.

The Angora Evaluation Methodology is Inadequate

In the Angora paper, the authors claimed to have investigated the efficacy of each contribution individually and proved the effectiveness of Gradient Descent. Unfortunately, the comparison they present to support this claim is biased towards Gradient Descent. They tried to compare the constraint-solving capabilities of random search, random search with magic byte extraction and Gradient descent. They collected an input corpus using AFL and then started Angora with each algorithm and the same input corpus. This way, all algorithms start with the same set of constraints to solve and the authors reported the corresponding solve rate for each algorithm. 

 
Since AFL uses random mutations to solve constraints, it is not surprising that all constraints that can be easily solved with random mutations have been already solved in the input corpus. This gives random search an immediate disadvantage. 

 
While inspecting the code of Angora, we also found another issue. The evaluation ([1, Section 5.4]) states that Gradient Descent is compared to random search with Magic Byte extraction. However, the Angora Gradient Descent implementation itself makes use of Magic Byte Extraction, thus guaranteeing that it always performs at least as well as its closest competitor in the comparison. This methodology is inadequate and the original conclusions about the efficacy of Gradient Descent are not supported by our research. 

 
The Angora authors state that their "exploitation routines are a part of the enhancements aforementioned. During gradient descent, Angora first descends by the entire gradient. Only when this fails to solve the constraint does Angora try to descend by each partial derivative as a crude attempt of salvation." [5] According to our findings, however, these heuristics dominate the search of Gradient Descent for constraints with a large number of input dimensions – a fact that should have been discovered in an adequate evaluation setting.

Odd Heuristics and Parameters

The Angora code contains a number of optimizations and behaviors that are not documented in the paper. While the volume of information that can be published in a paper is limited, many of these had a significant impact on the potential performance; yet, they are not documented or motivated in the released source code. These are some examples:

• The Gradient Descent implementation goes beyond what is described in the paper. It contains special exploitation routines that inject fixed values that are known to trigger overflows and numerical bugs. The algorithm also does not only use the entire gradient but instead descends by each partial derivative.
• Parameters like the optimization budget are set to fixed, arbitrary values without justification or documentation for the chosen parameters:

  // SEARCH
  pub const ENABLE_DET_MUTATION: bool = true;
  pub const MAX_SEARCH_EXEC_NUM: usize = 376;
  pub const MAX_EXPLOIT_EXEC_NUM: usize = 66;
  pub const MAX_NUM_MINIMAL_OPTIMA_ROUND: usize = 8;
  pub const MAX_RANDOM_SAMPLE_NUM: usize = 10;
  pub const GD_MOMENTUM_BETA: f64 = 0.0;
  pub const GD_ESCAPE_RATIO: f64 = 1.0;
  pub const BONUS_EXEC_NUM: usize = 66;
  

  
  Values like MAX_SEARCH_EXEC_NUM (376; the number of iterations to solve a constraint) or BONUS_EXEC_NUM (66; the number of additional iterations added under certain conditions) would be odd choices in an experiment design; computer scientists would normally prefer multiples of powers of 10, 2, or 5. These choices are not justified or documented; and in any case, the impact of these choices (compared to others) would have to be determined.
  The value of 376 for MAX_SEARCH_EXEC_NUM is a particularly odd choice. Since the few constraints that Gradient Descent operated on were actually either solved after a maximum of 50 iterations or not at all, setting the iteration budget to at most 50 should actually increase the performance on LAVA-M.

The Angora authors confirm that the "current values seem to work well on most programs, but we did not rigorously evaluate them or search for their optimal values." [5] This implies that the authors themselves do not know which factors contribute to Angora's evaluation performance, or why their choices would be particularly well suited to settings outside of the evaluation.

Reproducibility

All of the above findings refer to the published Angora code, which may differ from the one used in the paper evaluation. We have therefore asked the Angora authors to provide us with the version used for the experiments described in the paper. They said that they "have been steadily maintaining and improving the Angora repository over the past year, with numerous bug fixes and enhancements. Its current performance is similar to, if not better than, the version on which our paper's evaluation was based." Unfortunately, the history of the public repository does not go back to the time the paper was published, and our request for the original version remains unfulfilled. We do not know whether the Angora authors would be able to reproduce their published results.

Summary

The performance and effectiveness of the Angora tool are uncontested, notably on the LAVA-M benchmark. If you want to fuzz a program that is part of the LAVA-M benchmark or very similar, Angora is likely to give you good results. Finally, the authors are to be commended for making their code available, and for providing detailed and timely answers to our questions. However,

1. Angora's novel Gradient Descent approach has little to no impact on its performance on LAVA-M;
2. The performance of Angora is impacted by several decisions that are not documented, motivated, assessed, or evaluated individually or sufficiently; and
3. The evaluation methodology is inadequate to support the paper's conclusions on Angora's performance.

Guidelines for good scientific practice mandate that all information and decisions that helped to achieve a specific result be well documented. This is not the case here – neither in the paper nor in the code.

It would be a mistake, however, to point at the Angora authors only. Chen and Chen did make their code available, allowing for independent assessment. Several recent fuzzing papers use similar techniques and benchmarks as Angora, yet only few make their code available. Can we trust their results?

This calls for the community to discuss and question its procedures and criteria on what makes good research. Reviewers and researchers must not only focus on great results, but also assess how these results have been obtained, whether they have been rigorously evaluated, and how they translate into insights that will stand the test of time. How this can be achieved for programs with thousands of lines of undocumented code is a pressing question.

For now, the Angora case tells us how much we do not know, and how much further insights into what works and what does not will be needed. The good news is that this opens lots of opportunities for discussion – and future research.


Acknowledgments.  Marcel Böhme, Cas Cremers, Thorsten Holz, Mathias Payer, and Ben Stock provided helpful feedback on earlier revisions of this post.  Thanks a lot!

If you liked this post, also see our follow-up post with consequences.

You can contact Kai Greshake as development@kai-greshake.de.

References

• [1] P. Chen and H. Chen, "Angora: Efficient Fuzzing by Principled Search." 2018 IEEE Symposium on Security and Privacy (IEEE S&P), San Francisco, CA, 2018, pp. 711-725.
• [2] K. Greshake, “Effective Search Algorithms for Grey Box Fuzzing” BSc. Thesis at Saarland University, August 2019.
• [3] B. Dolan-Gavitt et al., "LAVA: Large-Scale Automated Vulnerability Addition," 2016 IEEE Symposium on Security and Privacy (IEEE S&P), San Jose, CA, 2016, pp. 110-121.
• [4] Valentin J.M. Manes, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, Maverick Woo, "The Art, Science, and Engineering of Fuzzing: A Survey". arXiv:1812.00140
• [5] P. Chen, H. Chen, A. Zeller. "Questions on Angora tool vs Angora paper". E-mail exchange, September/October 2019.

Where your conference fees go to

Fees for scientific conferences can be a cause for concern. Since most researchers are paid by public money, the question is whether this money is put well to use.  So where do your conference fees go?  Let me illustrate this on an example – the ISSTA conference I organized in 2016.

ISSTA is a nonprofit event, run by dozens of volunteers who run the conference as part of their paid job (or throw in extra hours for fun and honor); none of the researchers presenting, reviewing, or organizing make any profit from this.  ISSTA is run by ACM, which means that it covers losses but also gets any surplus; again, ACM is a nonprofit organization.

ISSTA 2016 attracted 113 visitors to its main conference, and 48 visitors to its workshops.  As with most conferences in our domain, students make the majority of visitors to the main conference, followed by ACM members.  (As an ACM member, you get a discount that is higher than the annual ACM membership fee, so it pays off to join ACM even if just for one year.)

Registration fees for the main conference vary between 300€ for students registering early and 750€ for non-members registering late; workshops fees were between 125€ and 300€.  On top of these fees comes a VAT of 19%.  These attendees make the conference, and their fees make the conference income – in the case of ISSTA 2016, exactly 70,460€.

When setting up the budget, you make non-students subsidize students: At ISSTA 2016, an additional student would actually incur a small cost; but this would easily be covered by additional non-students coming in (especially when showing up on-site!).  We also got a small amount of donations; other conferences and conference chairs are much better at getting these.

Of course, you do not know how many people will attend, so you calculate conservatively – I estimated 100+ visitors for the main conference, and planned accordingly.  The key point in planning, though, is the expenses.  This is what the expenses for ISSTA 2016 eventually broke down to:

Starting clockwise at the top, the biggest category is food and drinks, including social events like reception and dinner.  We spent about 50€ per person and day, which is pretty reasonable for two full meals, coffee, drinks, snacks, and all.  We ran ISSTA at my university, meaning that we could buy drinks and snacks at retail price; if you run a conference at a hotel, you would be charged hotel prices, say $3 or more for each and every can of soft drink, and you don't want to know about beer or wine. Workshops at ISSTA 2016 had relatively high fees, but little cost (essentially coffee, cookies, and a light lunch), and thus brought in revenue.  All expenses also incur taxes – in our case, again 19% VAT.

The next big block is registration, which covers most of actually organizing and running the conference.  Most of this is the fee charged by the conference organization agency of my university. They run a few dozen conferences every year and are very well-organized: their fee includes organizing costs (the folks who answer your queries and write visa letters), university overhead, and more. This item also includes the staff on site – in our case, student aides who gave out bags, served drinks, handled your queries, or oversaw the AV – as well as free bus tickets for all attendees (rides from hotel to the conference venue and back).  Overall, I estimate that the agency saved me two months full time of planning and organizing, so contracting them was a great return on investment.

Financial refers to 2% credit card fees.  Depending on your country and your financial provider, these may vary considerably.

ISSTA features a physical meeting of the program committee – that is, all reviewers meet for two days to discuss which papers should be presented.  This contributes to the quality of the conference, but also is very expensive.  The reviewers have to assume their travel, and the conference pays for meeting rooms, day catering, and a dinner.  We co-located the PC meeting with the ICST 2016 conference in Chicago.  This attracted more attendees to ICST; in return, ICST subsidized the PC meeting from the extra revenue, keeping the cost low.  This item also includes invited speakers, for whom ISSTA 2016 covered travel expenses as well as free conference and workshop tickets.

On-site logistics primarily refers to meeting rooms. These can be expensive, depending on the venue.  My university has reasonable prices for scientific meetings, including all technical equipment. Hotels often offer meeting rooms for free if you bring in sufficiently many guests, but then they may charge you for extras such as AV or Wi-Fi – and the rental of a single AV system can easily exceed the cost of an entire meeting room at the university.

The program needs to be printed; for publicity, we distributed leaflets at conferences and otherwise used free Facebook and Twitter channels. Other conferences would throw in paid advertising and throw in extras such as the proceedings on a USB stick.  ISSTA gave you a linen bag and an online access code for the proceedings.

Conference management refers to services around the conference, notably Proceedings, the cost of editing the accepted papers and making sure they all end up in the digital library, all properly tagged; as well as the Conference Management System, which handles submissions and the review process.  We used specialized services for both, again at reasonable cost.

Low cost and high attendance, especially at workshops, gave ISSTA 2016 a high surplus of 25,000€ – which all went to ACM such that ACM and SIGSOFT could keep on organizing and supporting research in our field.  Note, though, that such a surplus is not the rule.  You are supposed to plan for some contingency and overhead, but most conferences have a much smaller surplus. Despite best efforts of conference organizers, some conferences come up with a loss that would then be covered by the sponsoring society.  With ISSTA 2016, we were lucky – and if you ever go and organize a conference, I wish you the same luck, too!

I am leaving Saarland University, and the call for my successor is open

This year, I will leave Saarland University, where I have been professor for software engineering for 16 years.  Our CISPA Center for IT Security is about to segregate from Saarland University to become a Helmholtz Center, and I will be moving with it.

With base funding for 500 researchers, the new Helmholtz Center is set to become one of the largest research institutions in IT security – and hopefully one of the most renowned, too.  The recent research of my group in program analysis and test generation (watch out for papers this year!) positions us right at the intersection of software engineering and security, and I will be happy to contribute both to the research agenda as to the management of CISPA.  I will retain a footprint at Saarland University, though, keeping my professor title and reduced teaching obligations.

While the label on my office will change, my loyalty to the Saarland Informatics Campus will not falter the slightest.  I am grateful to work in one of the greatest research environments that could possibly exist, surrounded by colleagues who have proven their incredible excellence again and again, and who all work together every day for the excellence of the site as a whole.  When I started 16 years ago, we were maybe 15 professors in Computer Science; when I retire, there will be ten times as many.

This great environment can be your environment, too.  If your work is related to IT security, please check out our tenure-track and tenured career options at CISPA.  If your work is in Software Engineering, though, the call for my successor (German / English) is open as well.  It has been one of the best positions I could ever think of, and I am sure it could be the same for you!

The Rejection Song

To be performed by a scientific program committee (choir) and its chair (solo voice) to the tunes of the song "Go West" (Village People / Pet Shop Boys).  A program committee decides which scientific works get published.

(Together) We‘re the committee

(Together) We‘re the experts, see?

(Together) We will read your work

(Together) We will make us heard

Re-ject! This is our song

Re-ject! cos the data‘s wrong

Re-ject! it’s been done before

Re-ject! send it out the door

(Together) We select the best

(Together) We reject the rest

(Together) and the best is us

(Together) so why make a fuzz?

Re-ject! This is out of scope

Re-ject! it’s a slipp‘ry slope

Re-ject! It’s irrelevant

Re-ject! I don’t understand!

(Together) We define the field

(Together) We do form a shield

(Together) We are the elite

(Together) Life can be so sweet

Re-ject! no related work

Re-ject! you are such a dork

Re-ject! not my expertise

Re-ject! would you fix that, please

Re-ject! cos it’s really bad

Re-ject! cos I’m getting mad

Re-ject! there’s a missing bit

Re-ject! it‘s a piece of (fade out)

Music: Victor Willis, Henri Belolo and Jacques Morali

Above lyrics: Andreas Zeller

Mit dem Fahrrad aus der Saarbrücker Innenstadt zur Uni

Ich bin die meisten Tage des Jahres mit dem Fahrrad aus der Saarbrücker Innenstadt zur Uni und zurück unterwegs.  Für alle, die auch gerne mit dem Fahrrad zur Uni wollen, habe ich hier meine drei Lieblingswege auf einer Google-Karte zusammengestellt; Details folgen unten.



Und hier sind die drei Wege, sortiert von Nord nach Süd:

Der Schnelle: Am Meerwiesertalweg entlang

Ein nützlicher Weg, getrennt geführt neben starkem Autoverkehr.

Hier geht es lang: Vom Hauptbahnhof aus über den Bormannpfad (Alternative: durch Parkhaus Hela schieben), die Dudweilerstraße kreuzen und auf den Meerwiesertalweg.  Dort führt ein für Radfahrer freigegebener Radweg immer geradeaus mit zunächst moderater Steigung bis hoch zur Uni. Auf dem letzten Stück zwischen Uni-Parkhaus und Pforte wird es steil.

Ein Weg für: Normalfahrer, die schnell von A nach B wollen.

Aufpassen: Am unteren Ende des Meerwiesertalwegs sind zahlreiche Einmündungen, wo Autofahrer  insbesondere von den stadteinwärts auf der linken Seite fahrenden Radfahrern überrascht werden; erst ab der Jugendherberge wird es entspannt.  Der Weg am Meerwiesertalweg ist ein für Radfahrer freigegebener Gehweg, also gilt es, besondere Rücksicht auf die (wenigen) Fußgänger zu nehmen.  (Radfahrer dürfen zwar auch auf der Fahrbahn des Meerwiesertalwegs fahren, was aber wegen starken Autoverkehrs auf enger Fahrbahn keinen Spaß macht.)

Bester Moment: Wenn es auf dem Rückweg am Parkhaus entlang steil herunter geht – das ist der Rücksturz zur Erde.

Alternativen: Innenstadt über Scheidter Straße verlassen (siehe unten), dann über den Ilseplatz und Waldhausweg in den Meerwiesertalweg umschwenken.  Wer die Steigung am Parkhaus nicht mag, kann auch das Gelände der Sporthochschule erkunden.

Der Sportliche: Durch den Stadtwald zur Uni

Mein morgendlicher Weg zur Uni – steil und schön

Hier geht es lang: Die Innenstadt über Beethovenstraße/Blumenstraße verlassen (eine ruhige Strecke entlang Einbahnstraßen, die laut Verkehrsentwicklungsplan irgendwann zur Fahrradstraße ausgebaut werden soll), auf die Scheidter Straße wechseln und bis zu deren Ende immer höher fahren.  Hinter der Wendeschleife geht es in den Wald, wo wir sofort links an der Schranke vorbei auf einen asphaltierten Waldweg wechseln, der uns bis zur Uni führt. Der Weg führt steil durch den lauschigen Stadtwald hinauf.  Etwa auf halbem Wege geht es dann bergab, man rollt entspannt zur Uni herab, und lässt den Schweiß im kühlenden Fahrtwind zurück.

Ein Weg für: Mountainbiker, Elektroräder, Naturliebhaber.

Aufpassen: Der Radweg entlang der Scheidter Straße ist durch parkende Autos von der Fahrbahn getrennt; ausfahrende und parkende Autofahrer übersehen hier Radfahrer gerne.  Der Waldweg ist unbeleuchtet; Schnee wird spät geräumt.  Auf dem Rückweg geht es auf der Scheidter Straße steil bergab, also besser auf der Fahrbahn bleiben.

Bester Moment: Morgens im Wald den Berg hinauf.  Nichts zu hören außer Vogelgezwitscher.

Anschlüsse: Noch höher hinaus?  Auf den Schwarzenbergturm für ein kleines Workout und oben die Aussicht genießen.

Der Flache: Über Schafbrücke und Scheidt

Feierabendstrecke mit nur moderaten Steigungen, die Hälfte auf ruhigen Wegen.

Hier geht es lang: Die Innenstadt an der Saar entlang verlassen; spätestens an der Ostspange nach links abbiegen und auf die B51 nach rechts fahren. Auf dem Radweg geht es an der B51 eher unproblematisch immer geradeaus. Nach den Römerkastell geht es auf einer Fahrradspur leicht bergauf; danach geht es nach links in die Breslauer Straße, und dann gleich rechts auf die andere Seite der Bahnstrecke.  Jetzt kommt der schöne Teil: Es geht auf ruhigen Wegen durch Schafbrücke immer an der Bahn entlang, bis wir in Scheidt nach der Überführung links abbiegen und wieder mit leichter Steigung zur Einfahrt Ost der Uni fahren.

Ein Weg für: Entspannte Kilometerfresser.  Leute, die zum Ostteil der Uni wollen.

Aufpassen: In der Innenstadt sind entlang der Mainzer Straße wie auch an der Saar viele Fußgänger unterwegs, also Rücksicht nehmen. Der Abschnitt Römerkastell-Breslauer Straße ist verkehrsreich; beim Linksabbiegen in die Breslauer Straße auf eine Rotphase warten, dann den Extra-Wartebereich für Fahrradfahrer nutzen, um sich links einzuordnen. Von Scheidt zur Uni führt der Radweg getrennt auf der linken Seite entlang; Vorsicht bei Einmündungen.

Bester Moment: Auf ruhigen Wegen flott durch Schafbrücke.

Alternativen: Zwischen Römerkastell und City sind Preußenstraße und/oder Halbergstraße verkehrsarme Fahrrad-Alternativen zur B51.  Wer im Saar-Basar einkaufen mag, kann das Gelände im Westen über eine Pforte via Eschberger Weg und Im Heimerswald erreichen.  Statt des asphaltierten Radweges von Scheidt zur Uni kann man auch am Rückhaltebecken links abbiegen und einen unbefestigten Waldweg nehmen.

Anschlüsse: Sehr schöne Radwege gibt es die Saar entlang Richtung Saarlouis oder Sarregemuines.  Der Radweg nach Scheidt führt auf ruhigen Wegen weiter an der Bahn entlang Richtung St. Ingbert.  Alle Radwege sind ausgeschildert.

Hinweis: Als Rückweg (also von Uni zur Innenstadt) attraktiver, da (a) leichtes Gefälle (b) am Römerkastell weniger Kreuzungen und (c) der verkehrsreiche Abschnitt zwischen Breslauer Straße und Römerkastell ist schnell überwunden. 

Twelve LaTeX packages to get your paper accepted

(with Abhik Roychoydhury and Aditya Kanade)

Why do some people get all their papers accepted, and others do not?  You may already know that in many disciplines, using the LaTeX typesetting system correlates with having your paper accepted (in contrast to, say, Word).  What you may not know is that there is a number of LaTeX packages whose usage may be crucial for success.  Here we go:

1. The pagefit package.  This immensely useful package makes your paper exactly fit within a given page limit, applying a genetic search algorithm to reduce baseline distances, white space, font sizes, or bibliographic references until it exactly fits.  Just write \usepackage[pages=12,includingbibliography]{pagefit} and enjoy.  
2. The autocite package. Cites all relevant work that needs to be cited.  The "citepc" option additionally cites the entire program committee, whether their work is relevant or not.
3. The translate package.  Auto-translates your paper into a given target language (default is English).  Just type

PostDoc Position, Software Testing and Analysis / Software Engineering

At my Chair at Saarland University, we currently have a PostDoc position available, to be filled during the Spring of 2017.  We are looking for applicants in all areas of Software Engineering, with a special focus on experience in

• Software Testing and Analysis
• Security and Privacy
• Specification and Specification Mining
• Data Mining and Machine Learning

Your job is to conduct bold and risky research, possibly interacting with the several great PhD students at the chair.  Our most recent projects include

• mining of input grammars to create powerful fuzz testers,
• mining thousands of apps to detect UI inconsistencies, and 
• mining sandboxes as a universal security solution.

If such work inspires you, and if you see chances to combine your expertise and creativity with ours, we'll be happy to hear from you.  Please have a look at the official announcement and apply before December 1.

On Facts and Dreams in Software Research

Where is the economic argument in program verification research, and where are the salvation messages in software engineering research?

I just had the pleasure of attending David Rosenblum’s keynote at ASE 2016, in which he praised the power of probabilistic thinking (using stochastic reasoning to estimate risks and support decisions) versus an absolutistic view in which there is only 100% truth or 100% failure.  His takeaway message was that software engineers should embrace probabilistic methods and permeate them throughout the development process.

As a software engineer, probabilistic thinking is a central part of my day-to-day job – in development as in research.  Whatever I build and design, I think about how useful it might be, which benefits it may bring, and what the associated risks are.  In Software Engineering research, the dominating metric is usefulness, which eventually translates into an economic argument: What does it cost? What are the benefits? What are the risks?  These are day-to-day questions in software development, and my research is expected to provide facts to help answer them.

In other fields of computer science, such as software verification, the economic perspective is much less argued about.  Instead, the message touted is an absolutistic message of salvation: If you apply this technique, you will get a 100% guarantee that your software satisfies certain requirements – that the computation will be correct, that it will not crash, or that it will terminate within specific time bounds.  For developers and society, this message feels like the second coming of Christ: The day will come and all your problems will be gone.  

Up to now, there are great examples of how software verification works, and there are impressive examples of it being successfully used in practice; and just to be clear: By no means would I want to reduce these research efforts.  But the systems formal verification is applied to are still small and constrained; and getting it to scale and widen will require enormous human effort reshaping existing systems – before salvation comes repent.  Do we actually know how costly formally verified software is?  Do we know how to teach its techniques to developers who do not hold a PhD?  Can we estimate the risks it brings to rely on freshly written specifications, rather than on mature systems?  Might "good enough" software be good enough?  When talking to researchers in software verification, such economic arguments are frequently missing in the debate. But as a society, we need to understand where money is best spent, and answers to such questions could very well guide the field of software research.

Conversely, just as formal verification may benefit from introducing an economic perspective, Software Engineering may profit from adapting a stronger salvation perspective.  What is it that Software Engineering research could produce that would be seen as a salvation in software development – a significant reduction of costs or risks?  Recent topics that come to my mind are automatic software debugging and repair, steering development processes based on mining software histories, or massive automated test generation.  Can we translate our capabilities into grand challenges that will provide salvation in the future, possibly even including guarantees?  Yes, I know there are “no silver bullets” in software development.  But any great research community should pursue great dreams as well as provide facts – and in this, all of us computer science researchers are in the same boat.

Spiegel Online nutzt unsichere Cäsar-Chiffre: So lassen sich Spiegel Plus-Artikel lesen, ohne zu bezahlen

Der Spiegel-Verlag wagt einen neuen Versuch, mit Online-Journalismus Geld zu verdienen: Mit "Spiegel Plus" werden einzelne Artikel aus dem Online- und Magazin-Angebot gegen Geld angeboten.  Ich finde das aus mehreren Gründen gut:

• Guter Journalismus will bezahlt werden
• Ich zahle lieber für Artikel, als dass ich mit Werbung zugefüllt werde; und 
• Ich bin sowieso Spiegel-Abonnent und kann somit ohnehin auf die Artikel zugreifen.

Die Art und Weise, wie Spiegel Online seine Paywall implementiert hat, ist allerdings noch verbesserungsbedürftig: Jeder Depp mit elementaren Programmier- und Verschlüsselungskenntnissen (= ich) kann die Sperre bequem umgehen, und mit Verfahren, die sich in jedem Kindersachbuch zum Thema Verschlüsselung finden lassen:

1. Man nehme einen Mac und surfe mit dem Safari-Browser die gewünschte Seite an – etwa diese.  Es folgt die Zahlungsaufforderung.  (Dummerweise gibt es keine Möglichkeit für Abonnenten wie mich, sich einzuloggen – was die nächsten Schritte motivierte.)


2. Man schalte den Browser in den Lese-Modus (Shift-Command-R).  Jetzt kommt der gesamte Artikel – allerdings ist der zu bezahlende Teil verschlüsselt.
3. Offensichtlich werden hier einzelne Zeichen durch andere Zeichen ersetzt – Leerzeichen und Absatzzwischenräume sind nach wie vor erkennbar.  Gleich zwei Absätze beginnen mit "Jo" – offensichtlich ein häufiges Wort.  Nehme ich jeweils den vorangegangenen Buchstaben, erhalte ich hier "In".  Gleichermaßen wird "Tfju" zu "Seit", und "Ebt" zu "Das".  Die Entwickler haben den Text mit einer Cäsar-Chiffre verschlüsselt – jeder Buchstabe wird durch seinen Nachfolger ersetzt.  Das ist das einfachste und unsicherste Verfahren der Verschlüsselung – und eine Beleidigung für jeden Sicherheitsexperten.

4. Wir markieren den verschlüsselten Text und kopieren ihn in die Zwischenablage (Command-C).  Dann surfen wir zu einer Seite, die die Cäsar-Verschlüsselung entschlüsselt – etwa hier.  Dort fügen wir den kopierten Text ins untere Feld, geben "1" als Verschiebung ein, und drücken auf "Decode" – und schon erscheint oben der entschlüsselte Artikeltext.  Umlaute und "z" sind zwar noch kaputt, aber dies sei dem geneigten Programmierer zur Übung überlassen.


Danke, lieber Spiegel, dass Du Dich seit Jahrzehnten an die Speerspitze des deutschen investigativen Journalismus stellst.  Jetzt musst Du nur noch das Schlusslicht in Sachen Verschlüsselung abgeben, und Du hast meinen vollen Respekt.  Kleiner Tipp: Unser CISPA-Institut gibt gerne Hinweise zu sicheren Verschlüsselungs- und Zahlungsverfahren :-)

Update vom 29.06.2016: Matthias Streitz von der Spiegel-Chefredaktion hat sich bei mir gemeldet – er dankt für den Hinweis und will prüfen, ob ihnen "noch etwas Schlaueres einfällt als die Cäsar-Verschiebung".  Ich bin optimistisch, dass ihnen das gelingen wird.

Update vom 20.06.2016: Die "niedrige Paywall" ist auch von anderen beobachtet wurden.

My first talk at a scientific conference: A complete and utter disaster

I am just returning from ICSE 2016 in Austin, Texas; and once more, I have been impressed by the great many research talks.  For many of the presenters, this might have been there very first talk, and I was happy to see that it went pretty well for everyone.  My very first presentation at a scientific conference did not go so well.  Actually, it was a complete disaster.  But it eventually made me a professor.

This happened in 1993, at the German Software Engineering "SE" Conference in Dortmund.  I was a PhD student in my second year, and my advisor, Gregor Snelting, had asked me to present a summary of our group's research.  At this time, we had worked on semantics-based retrieval of software components: You would enter the desired pre- and postconditions of your component in a search field, and the system would automatically retrieve a suitable component.  The novelty was that we were using theorem provers to find possibly weaker preconditions or possibly stronger postconditions.  At the time, theorem provers were just about to enter the programming language space, so this was all new and unheard of.

So, here I was, standing on the stage, in front of about 100 German-speaking SE researchers, presenting the NORA system.  (NORA stood for No Real Acronym.)  And I would be showing how to search for a function given a simple postcondition – something like

This, as the specialist will immediately recognize, is the postcondition for a sorting function: The output a'[] is sorted (1), and also is a permutation of the input a[] (2).  I think I was right in the middle of explaining the formula, when I saw that some member of the audience had stood up, looking right at me.  Then, with a defiant look on his face. he shouted:

"When I want to search for a sorting function, I do grep sort!"

"grep sort" is a UNIX command, and it would mean to simply search through a list of textual descriptions to find a sorting function.  The audience was absolutely silent.  For a second.  Then, the whole room erupted with laughter. I peeked at Gregor, my advisor, who was sitting in the front row.  He crossed his arms and then grinned at me: How would I get out of this?  I stammered something along the lines: Well, that's of course true, but assume you have no knowledge of sorting, you don't even know that the word "sort" exist, then with our method, you would still be able to find something.  The shouter would just chuckle, shake his head, and then sit down.  The idea that a programmer could not now what sorting means did not stroke him as realistic.

I was just about to recover from that blow and about to put up the slide with the theorem prover diagram, when the next guy stood up, a mocking smile on his lips.  "Yes?", I said.

"You know, to me this looks like a solution looking for a problem."

Again, the entire room erupted with laughter. I don't remember how I replied, but it was just as unconvincing as before.   I was finished, publicly humiliated and ridiculed.  Putting together the rest of my dignity, I quickly showed the remaining slides.  I think I got some applause at the end, and even a question.  Still, for the rest of the day, I was marked.  Every time a participant saw me, a smile would flash over her or his face for a fraction of a second, remembering my ridicule.

"Who were these folks?" I asked Gregor.  "Congrats", he said.  "These were Professors Manfred Nagl and Jochen Ludewig, two really big shots in Germany's Software Engineering.  You managed to provoke them.  That's good."  – "Good?" I said.  "These folks just ridiculed me in the front of the entire audience.  How would that be good?" – "Well, we'll be known!", he said.  "Yes, but for what?" I replied.  All the way home, I would be furious at these two hecklers who had so rudely ruined my presentation.  And I vowed that one day, I would become a real big researcher, and I would have the last laugh over them.

Over the course of the next twenty years, I would be busy fulfilling my vow, and yes, it sort of worked – never again would a member of the audience shout stuff at me.  (But then, this may also be due to me never again presenting formal methods at a Software Engineering audience.)  

The last laugh, though, never came to be. Two years ago, as I last met Professor Nagl and Professor Ludewig, I asked them whether they would still remember how we met the first time, with me on the stage, and them standing up in the middle of the talk; and I wanted to thank them for how their comments had fueled and ignited my ambition for decades.  Of course, they would not remember a thing.  For them, it was just a minor laugh among many.

The new ICSE Erdős penalty, or why we should create incentives for frequent reviewers

Ever heard of Paul Erdős?  The 20th century Hungarian mathematician is not only known for his numerous contributions to Mathematics, but also for his multiple collaborations, engaging more than 500 collaborators.  Frequently, he would just show up on their doorstep, work with them for some hours, and then get a joint paper out of that.  A low Erdős number indicates academic closeness to Erdős, and is something one can brag about at academic venues.  Yet, if today, Paul Erdős knocked on your door, and asked whether you would like to work with him, you should avoid any collaboration with him – if you work in Software Engineering, that is.  Why is that?

The International Conference on Software Engineering, or ICSE for short, is the flagship conference of the field of Software Engineering.  If you want to publish and present your greatest work, this is where you submit it.  An ICSE submission is reviewed by three peer researchers, whose assessment eventually determines whether your work is accepted or not.  Even if your work gets rejected, you at least get detailed reviews and high quality feedback.

Over the years, ICSE has observed that there were authors who apparently were way more interested in the reviews than in getting their papers accepted; authors who would submit up to ten papers, of which none got in; but the authors would at least get thirty reviews, all for free.  This motivated ICSE to install a new limitation: Any single author can now appear only on up to three papers.  If you have four papers ready for submission, then you are supposed to select the best three.

The ICSE program chairs argue that few authors and even fewer acceptances would be affected by this decision.  But the problem with this decision is not the factual impact.  It is the potential impact.  What if a modern Paul Erdős knocked on your door and offered you to work with him?  You'd have to say no, because he would have too many co-authored submissions already.  What if you could not submit to the past conference, because you were the one organizing it, and still have work that wants to get published?  What if four of your students all have great results at the same time, results that should be shouted out to the world?  Well, too bad: you can only submit three of them, causing depression in the fourth student how is left out.  None of these is likely to happen, but the fact that it could happen is causing concerns and anxiety, and rightly so.  An open petition asking ICSE to revert its new rules has gained dozens of supporters overnight. (Disclaimer: me too.)

The Software Engineering community has members who have literally devoted their lives to Software Engineering research.  They have no spouses, no kids, they work day and night.  The boys would be out for a skiing weekend, and the girls would be out in their summer clothes – these folks are busy on the paper that they hope will make them famous.  They serve on program committees, they write reviews, they organize conferences, they help others on their PhD theses.  They are amazingly productive both on their own work as well as on the work of others.  And these are the men and women whom the new ICSE rules send the message: Thank you, but no, thank you.

The problem of ICSE – and our community in general – is not so much an abundance of papers.  It is the lack of reviews.  It is our publications that determine our academic worth; much less so teaching; and even less so service. Great papers get you tenure and a raise, whereas great reviewing might get you a committee dinner.  Rationally thinking, why should one spend time on reviews while one might just write papers that would get reviewed by others?  Fortunately, the large majority of our community is still driven by the Categorical Imperative: We profit from the reviews of others, so we review their papers, too.  What we don't like is members who game the system by not only submitting lots of papers, but also not participating in the review process.

Therefore, what our community needs to do is twofold.  First, we need to think about reviewing processes that scale well and get high-quality reviews.  The ICSE program board model is a step in the right direction; a VLDB-like journal model might be even better.  Second, we should not penalize researchers for their own productivity; but instead create incentives for researchers who spend great effort on reviews and service.  Rule by the carrot, not by the stick.

Such incentives for service should not be monetary (these wouldn't motivate researchers anyway); nor should they result in a different reviewing or acceptance process (this would be perceived as unfair).  But how about raising the limit of submissions if you have a co-author who is also a frequent reviewer?  Or allowing reviewing volunteers to apply for a one-day extension to the conference deadline?  (You'd get plenty of applications on the last day :-)  Or provide "fast track" journal reviewing for those authors who sport a status of "distinguished reviewer"?  With such incentives, if a prolific reviewer like Paul Erdős knocks on your door, you would not boot him, but embrace him instead.

Four security flaws illustrated, all on one conference registration site

When you're organizing a big scientific conference – conventions where scientists from across the world would convene to exchange their latest and greatest –, you have to think about zillions of different things: rooms, projectors, food, coffee, budget, accommodations, badges, speakers, leaflets, dinners, just to name a few.  It is impossible not to make mistakes, but it is generally possible to fix them once you know.  The worst mistakes, though, are the ones you never thought they could be made.

Some time ago, I registered for one of these scientific conferences.  The process is simple: You enter your details, select optional packages, finally enter your credit card data, and you're done.  This being a computer science conference, you would think your data is all secure in the hand of experts.  As I can now tell you from experience, this assumption is wrong.  Very wrong.  This single registration system contained not just one security flaw, but four – all independent of each other.

My Registration Screen

Security Flaw #1: The identifiable ID, or How I would be able to access the data of every conference participant

The fun began when I got my confirmation e-mail.  Apparently, I was the first person to have registered with the conference – because my participant number was one.  ("Hey – look at me; I am participant number one!" I said.)  In my e-mail, I also got a link with which I would be able to access my registration.  Following it would immediately lead me to the above registration screen.



The link was a bit unusual, because it would not contain any other "secret" information or token other than my participant number, though.  (You might assume it would encode my name, my ZIP code, or some other information tied to me only.)  So I asked myself: What would happen if I change the link from "?parm1=1" to, say, "?parm1=2" – that is, participant number two?  I entered the link into my browser, and immediately, I saw the registration screen of Lars Grunske, a colleague of mine in Stuttgart, Germany.

Lars Grunske's registration screen

Now having the same privileges as Lars, I would be able to read and change all data at will.  The idea arose to have him buy a few extra dinner tickets at his expense, but only briefly so.  Trying the same for further participants gave the same (Hi Abhik!,  ¡Hola Yasiel!).

In 2011, a similar mistake was made by UNESCO, who also used consecutive numbers for its internship applicants, and who thus leaked hundreds of thousands of applicant records on the Web.  (German Article on Spiegel.de)  What do you do when you discover such a problem?  To protect the integrity of participant data, I dutifully reported the problem to the organizers, who immediately replied the issue would be fixed as soon as possible.

Lesson 1: When handling personal data, set it up such that access requires a secret that cannot be easily guessed.

Security Flaw #2: The Unsanitized input, or How I easily bypassed password checks

The next day, I got a new mail from the organizers.  In addition to lots of high end security stuff (which would not protect from guessing a participant number), they now had introduced a secret word only known to the registrant, commonly known as a password.



Okay.  I went to the site, and it indeed now requested that I enter my ID and password.

Revised login interstitial screen

Problem solved? Not at all.  I sent the above mail to my Post-Docs Marcel and Juan Pablo "JP" Galeotti, whom I had talked about the problem the day before.  Minutes later, Marcel Böhme sent me back an intriguing message:



Incredible.  Could one really attack the system this way?  Ten minutes later, JP chimed in with



Ha!  Indeed, this worked like a charm.  Eventually, I would simply enter "2' -- " as my ID, and any string as my password – and again, I would be Lars Grunske, and would be able to alter his data at will.  Likewise, anyone with the above trick could do the same to my data.

How does this work?  Internally, the conference registration system uses a database that is controlled by so-called SQL commands.  When I enter my ID, say, "1", and my password, say, "1234", the system selects my data from the database using a SQL command looking like this:

    SELECT * FROM REGISTRATIONS WHERE ID = '1' AND PASSWORD = '1234'

Note how the number I entered as ID ("1") becomes part of the command.  By entering "2' -- " as ID and "whatever" as password. we get the command

    SELECT * FROM REGISTRATIONS WHERE ID = '2' -- 'AND PASSWORD = 'whatever'

In a SQL command, anything starting with two dashes "--" is treated as a comment and ignored.  So the system simply fetches the data from the registrant whose ID is 2, ignoring the password.  This is known as a SQL injection attack, and the standard way to avoid these is to filter out all characters that would have a special meaning in SQL commands (like "'" or "--").

Refining my ID to, say, "2'; DROP TABLE REGISTRATIONS; -- ", I might even have been able to delete all registration data.  (I hope they do backups!)  How could one set up a SQL-based system and never have heard about SQL injection?  Now this was beginning to get embarrassing.

Lesson 2: When setting up a publicly accessible service, identify common attack vectors and protect against them – for Web sites: buffer overflows, SQL injection, cross-site scripting, etc.

Security Flaw #3:  Plaintext Passwords, or How I would now also steal personal passwords from all participants

But the embarrassment was not over yet.  Remember how the e-mail above asked users to set up their own passwords?  It turned out that the passwords were actually stored and displayed in the clear, as seen on Lars' revised registration screen:

Lars Grunske's registration screen, now with password

The password listed was Lars' password; saving it would allow me to log in with his user ID and password.  I could easily have skimmed all passwords of all participants and I could have logged in long after the SQL vulnerability had been fixed.

But storing passwords in the clear is a bad practice for many more reasons.  It gives the administrator access to all passwords, which provides an opportunity for thefts.  Plus, and this is probably the worst: Many people tend to use the same passwords for different sites.  Had Lars indeed changed his password as requested, and for instance chosen the same password he would use for Amazon or eBay, I would be able to log in at these sites on his behalf, and happily order stuff.

Had Lars used the same password he also uses for his mail, I could have accessed all of his passwords, everywhere – a simple click on "I have forgotten my password" links would have triggered "password reset" mails to his account, which I could easily have skimmed.  I'm a nice guy, so I did none of this.  (Plus, I have a cool joint research project with Lars.)

To cut a long story short: I sent another urgent report to the organizer, and hours later, the SQL vulnerability was closed.  The one we had found, that is.  No idea whether other vulnerabilities would be hidden somewhere in there, or how the system had been tested for security, if at all.

Lesson 3: Passwords should never be stored, displayed, or transmitted in the clear.  Store hashes instead; and if a user requests a new password, create a new one instead.

Security Flaw #4: Compromised Forever, or How nobody would be able to change their passwords

Was it really the case that Lars had ignored the instructions and kept his original password?  After all that had happened, I thought that maybe someone had done the same that I had done, and thus now had access to my conference password.  So I decided to change it online.  However, it turned out that changing the password did not work – you would always retain the old one, which would still be happily displayed for you.  The good news was that this way, nobody would have been able to reuse existing passwords – and anyway, had I really wanted my password changed, another mail to the organizers might have done the trick.  At this point, I decided not to further stress the relationship between the organizers and their software developers and leave this be.

Lesson 4: Always allow your users to reset their access data if they fear it may have been compromised.

All was well that ended well: The conference was truly magnificent, and as far as I know, nobody's data got compromised in any way.  Of course, anybody could have gone through the steps described above, skimming data without ever reporting.  But luckily, the first registrant (me) pointed out the issues before some fraudster could have spotted it, and of course, any of my colleagues would have done just the same.  When your customers are nice people, consider yourself lucky.

Post Scriptum: The Horrible Homebrew, or Why it may be better to build on well-tested platforms

This brings me to the meta lesson to be learned here – and this tells something about process rather than product.  If you set up a system from scratch, be it a conference management system, a shop, a student registration system, whatever, be aware of the many risks this entails, and be sure to have independent and thorough security testing.  Using an existing, established, well-tested system instead may lower risk and overall cost, even if it may cost more upfront.  When the damage is done, you wish you had decided differently – but then, it may be too late.

Final Lesson:  When deciding between building and using a system, consider all risks and associated costs. If you build a new system, thoroughly test it for security.  If you use an existing system, be sure it is well tested.

Mining Sandboxes for Security

For the past three years, my students and I have worked on a novel and general approach to address software security.  This week at CeBIT, we're happy to spread some good news.

The concept of "Mining Sandboxes" protects against unexpected changes of software behavior and thus drastically reduces the attack surface of software systems. Our "Boxmate" prototype automatically mines program behavior by executing generated tests, systematically exploring the program’s behavior together with the accessed resources. The collected behavior rules form a sandbox, which at production time prohibits behavior not seen during testing. This brings several compelling features:

No unexpected behavior changes. The mined sandbox prevents behavior changes caused by latent malware, vulnerability exploitations, malware infections, or targeted attacks.

Closing the backdoors. The mined sandbox protects against backdoors that would not be discovered during normal usage.

No malware patterns required. The approach assumes no information about earlier or future attacks; it protects against known and novel attacks alike.

No training in production. In contrast to anomaly detection systems, all “normal” behavior is already explored during testing. The program is protected even before its first deployment.

No code required.  We require no knowledge about source or binary code, and thus can handle obfuscated, obscure, or adverse programs.

Want to get a brief overview of how it works? Here's a video, narrated by yours truly:

Conceptually, the techniques of Mining Sandboxes scale to arbitrary code size and can be applied to mobile apps, embedded systems, and server software alike.  Mining sandboxes is fully automatic, such that vendors, developers, and users can mine, inspect, compare, and exchange sandboxes at any time.  And for the testing researchers among us: This research leverages the incompleteness of testing to turn it into an advantage; and to actually produce guarantees from testing.

At this point, all of this is still research, so you cannot yet buy this in a shop near you.  And as with any big set of benefits, there's also drawbacks, in particular with legitimate functionality not found during testing – and there's still loads and loads of things to do.  But our first results with our prototype on real-world apps are more than promising; we have a nice paper coming up at the ICSE conference in May 2016, Austin, Texas.  And I am even more excited about this work than any other pioneering work of ours before, even more than say, Delta Debugging, or Mining Software Repositories – because if it succeeds, it would not only impact the lives of software developers, but actually address many of the software security problems we see in the news every day.

If this has captured your attention, you can read more about the project at its site: http://www.boxmate.org/.  Or you can visit us at the CeBIT computer fair in Hannover between March 14 and March 18 (Hall 6, Stand D 28); I will be on site Monday and Tuesday.  I'd love to get engaged in discussions!