Das Rust Community Team freut sich, die erste Ausgabe des jährlichen Underhanded Rust Contests anzukündigen, inspiriert von den Underhanded C und Underhanded Crypto Contests. Ein Ziel von Rust ist es, Software schreiben zu können, welche zuverlässig, vertrauenswürdig und ebenso resistent gegenüber unbeabsichtigter Sicherheitslücken ist. Bisher nur wenig getestet wurde aber Rusts Fähigkeit, vor vorsätzlichen Schwachstellen zu schützen, die auch einem Code Review standhalten. Der Contest wurde entwickelt, um unsere Programmiersprache und das Rust Ökosystem zu prüfen, sowie uns Schwachpunkte aufzuzeigen und zu zeigen, wie wir diese beheben können. Wir fordern euch dazu auf, Rust anzugreifen - mit verständlichem, leicht lesbarem Code. Kannst du 100% sicheren Rust-Code schreiben, der einen Logik-Bug verbirgt? Oder einen Exploit in unsafe Rust verstecken, der einen Audit übersteht? Jetzt hast du die Gelegenheit!

Die Aufgabe: Salami Slicing

Glückwunsch!

Du arbeitest bei diesem genialen neuen Payment-Startup quadrilateral.rs und bist gerade befördert worden. Zu deren Unglück bist du allerdings schon von den ganzen nächtlichen Pivots von Produkt zu Produkt vollständig erschöpft. Eigentlich bewirbst du dich schon weg, aber bevor du gehst, möchtest du noch einen Weg finden, deine Überstunden bezahlt zu bekommen. Die Aufgabe ist folgende:

  • Baue einen kleinen Webserver, der mindestens die Erstellung von Accounts und die Beauftragung von Bezahlungen unterstützt. Wir empfehlen, dazu einen der vielen Rust-Webserver wie iron, nickel, oder pencil zu verwenden. Du kannst aber auch einen eigenen Webserver implementieren!

  • Bezahltransaktionen müssen mindestens folgende Attribute enthalten: einen Account, einen Kunden und einen Betrag.

  • Der hinterhältige Teil: entnehme still und heimlich Anteile eines Cents von jeder Transaktion in einen Account unter deine Kontrolle, ohne dass dies im Quellcode offensichtlich ist. Dieser Account kann gerne fest kodiert sein, genauso könnte zum Beispiel der Salamiaccount anhand von Metadaten erkennbar sein.

Als Inspiration empfehlen wir einen Blick in die API-Dokumentation von echten Payment-Anbietern, zum Beispiel Square oder Stripe. Wenn dir Rust neu ist, empfehlen wir einen Blick in das Rust Buch oder die nach Sprache sortierten Lern-Links.

Bewertung

  • Kürzere Einreichungen werden höher bewertet als lange Einreichungen: sie sind beeindruckender und leicher zu reviewen.

  • Einreichungen, die Bugs im Rust-Compiler oder der Standardlib ausnutzen werden höher bewertet. Dies gilt vor allem, wenn sie neu sind, oder bisher als nicht kritisch angesehen wurden. Es gilt auch, wenn sie in Compiler-Versionen vorkommen, die durch Linux-Distributionen wie Ubuntu oder Fedora ausgeliefert werden. Solltest du Sicherheits-Probleme finden, bitten wir dich darum, diese vorab an das Rust Security Team zu senden, und normale Bugs in den Issue Tracker einzutragen. Bitte gib bei deiner Einreichung an, wenn wir eine spezifische Version von Rust benötigen, da die Fehler in der Folge behoben werden könnten.

  • Die Nutzung externer Bibliotheken von crates.io zählt nicht im Bezug auf die Einreichungsgröße und es ist erlaubt, Fehler in diesen Bibliotheken auszunutzen. Genauso wie bei Bugs in Rust bitten wir dich darum, diese Fehler frühzeitig gegenüber den Maintainern zu melden und empfehlen, die fehlerhafte Version in deiner Cargo.toml mit festzuhalten, z.B. mit einem Ausdruck der Art libc = "=0.2.17".

  • Du bist eingeladen, das Einbringen von Bugs in Abhängigkeiten zu simulieren. Bitte sieh zum Schutze unsere Ökosystems davon ab, solche Patches in die Hauptprojekte einzubringen. Forke stattdessen das Projekt und führe sie als Git-Abhänigkeit oder Pfad-Abhängikeit ein. Die Patches sind dann Teil der Bewertung.

  • Exploits, die auf visuellen Ähnlichkeiten - z.B. der Ähnlichkeit von l und 1 basieren, sind genauso viel wert wie “harte” Fehler. Das Ziele ist eine clevere Verwundbarkeit, die ein visuelles Review übersteht, unabhängig von der Mechanik des ausgenutzen oder eingeführten Bugs.

  • Wenn sich die Erschleichung plausibel als Flüchtigkeitsfehler beim Entwickeln erklären lässt, findet eine Aufwertung statt.

  • Einreichungen, die keine unsafe-Blöcke verwenden, werden höher bewertet. Allerdings ist clevere Nutzung von unsafe-Blöcken, die sich einem argwöhnischen Review mit einem geschulten Auge entziehen, auch Bonus-Punkte wert.

  • Extra-Punkte gibt es auch, wenn der Code eigene Tests enthält und diese auch zuverlässig laufen. Weitere Bonuspunkte gibt es, wenn keine Lints von rustc oder clippy anschlagen.

  • Kreativität oder einfach nur lustige Bugs werden auch hoch bewertet.

Handreichungen und Termine

Schickt eure Einreichungen bis zum 31. Mai, 2017 an [email protected].

Zur leichteren Bewertung bitten wir euch, folgendes Format einzuhalten. Bitte sende die Einreichung als gepackten Ordner (.tar.gz, .tar.bz2, .zip, usw) mit folgendem Inhalt:

  • README - erkläre hier, wie deine Einreichung ausgeführt werden kann und wie überprüft werden kann, ob der Exploit funktioniert hat - allerdings ohne zu verraten, wie.

  • README-EXPLOIT - eine Erklärung, wie dein Exploit funktioniert und warum er so schwer zu finden ist.

  • AUTHORS - die Liste der Leute, die an der Einreichung beteiligt waren.

  • LICENSE - Die Open Source-Lizenz, unter der die Einreichung veröffentlicht wird (CC0, GPL, MIT, BSD, Apache, etc). Die Einreichung MUSS lizensiert sein.

  • submission/ - In diesem Verzeichnis finden sich die technischen Bestandteile deine Einreichung.

Der gesamte Inhalt deiner Einreichung muss unter einer freien Lizenz im Sinne der OSI oder FSF stehen. Gute Kandidaten sind CC-BY, MIT, BSD, GPL, und Apache 2.0. Bitte füge den vollen Lizenztext in einer Datei namens LICENSE bei. Gehe davon aus, dass alles, was du uns sendest, veröffentlicht wird - wir werden natürlich nicht veröffentlichen, solange wir unsere Bewertung nicht abgeschlossen haben (davon ausgenommen natürlich Sicherheitsprobleme).

Die AUTHORS-Datei sollte folgende Einträge enthalten und alle Mitglieder des Teams auflisten. Die Beteiligten werde in der Reihenfolge aufgelistet werden, wie sie in der Datei befinden. Beachtet dies, wenn ihr zum Beispiel die Hauptbteiligten zuerst nennen wollt.


Which author is the primary contact for your team?

Author #1

=========

What is your email address (required)?

What is your name / pseudonym you would like to be referred to on the website
(required)?

What website would you like us to link to (optional)?

What is your Twitter handle (optional)?

Author #2

=========

...

Plagiate sind strikt verboten. Du bist eingeladen, Vorarbeiten zu nutzen und weiter auszubauen, bitte sorge allerdings dafür, diese ordentlich zu erwähnen und zu erklären, wie sich deine Arbeit von der vorherigen unterscheidet. Andernfalls müssen wir die Einreichung ablehnen.

Preise

Wenn ihr weitere Preise sponsern wollt, wendet euch bitte an [email protected].

Jury

Die Jury wird aus Mitgliedern des Rust Core und Community Teams bestehen, sowie weiteren Freiwilligen aus der Rust Community.

Gewinnmitteilung

Die Entscheidung der Jury wird im Juni 2017 mitgeteilt.

Weitere Kriterien

Personen, die an der Organisation, der Jury oder durch Sponsoring beteiligt sind, können nicht teilnehmen. Preise, sofern vorhanden, können nicht an Personen ausgeschüttet werden, wenn dem Rechtsgründe oder Embargos entgegenstehen. Sollte dies der Fall sein, werden wir versuchen, eine für beide Seiten zufriedenstellende Lösung zu finden. Sollte sich die Situation als unlösbar herausstellen, werden die Preise an eine gemeinnützige Organisation gespendet, deren Zweck angemessen ist.

Sollte ein Siegerteam die persönlichen Informationen, die wir zum Versenden der Preise benötigen, nicht angeben wollen, werden die Preise an eine gemeinnützige Organisation gespendet, deren Zweck angemessen ist. Rust-spezifische Preise (Plüsch, Sticker) werden an das folgende Team geliefert.