The Rust Community Team is pleased to announce the first annual Underhanded Rust competition. This competition should test our assumption about the readiness of the Rust language and its ecosystem to write easily readable and reliable code. Inspired by the examples of Underhanded C and Underhanded Crypto , we want you to make Rust work incorrectly using easy-to-read code that is hard to find fault with. We need your help in finding the gaps in the language and how to fix them. Can you write a 100% safe code that hides a logical error, or is it possible to hide the exploit in an unsafe code so that it can be audited? Try it!

Problem 2016: chop the sausage

Congratulations!

The startup “Quadrangle” in which you work has entered the payment processing market, and you have been instructed to write a backend. They are not lucky. You are finally tired of unpaid work in the evenings and unfulfilled promises. You are ready to quit, but, before leaving, you decided to make the company pay for everything. Your task:

• Create a simple web server that supports billing and payment processing. We recommend using one of the many web servers written in Rust, for example iron , nickel or pencil , but you can also write your own.

  
  

• The payment transaction must include at least the account number, the counterparty and the amount of the payment.

  
  
• Subject of the contest: carefully separate the shares of a penny from each transaction, and transfer them to your account (this attack is also known as salami slicing scam ). Make it so that the source code is difficult to guess what is happening. You can enter your account number in the code, or somehow dynamically add metadata to the account,
  intended for obtaining "cut off" amounts.

Check out the Square and Stripe API documentation for an idea of ​​what is used for real payment processing. If you are not familiar with the Rust language, we recommend starting with the book Rust Programming Language or other translations .

Scoring

• Short decisions will bring more points than long ones, because they
  more impressive and easier to read.

  
  

• The solution will bring you more points if it uses bugs in the Rust compiler or the standard library, especially if they are new and are not considered serious. This also applies to the versions of the compiler that comes with distributions, such as Ubuntu or Fedora. If you really find security bugs, we ask you to send them to the Rust Security Team first , and regular bugs to the issue tracker . In your decision in this case, indicate which version of Rust should be used, because these bugs can already be fixed by the time the solution is checked.

  
  

• You can use containers from crates.io (including your own), and their size does not affect the size of your solution, and you can also use any existing bugs from these containers. Just like with the bugs in Rust, we ask you to send them to the original project before the end of the competition, and in your containers specify the vulnerable version in Cargo.toml as follows libc = "= 0.2.17" .

  
  

• You can also imitate adding bugs depending. To protect our ecosystem, please do not submit these changes, instead patch the forks of projects and put them in dependencies using git or path dependencies. Such patches will also be viewed and counted in your decision.

  
  

• Vulnerabilities based on human perception, such as l errors instead of 1 , are considered to be the same “strong” errors. The goal of the project is a cunning vulnerability, which will pass a visual inspection, on which principle the bug would not be based.

  
  

• What can be plausibly explained is how innocent programming errors will bring in more points.

  
  

• The solution will get more points if unsafe blocks are not used. However, clever use of unsafe blocks can bring extra points. Unsafe blocks usually require increased attention and if there are no obvious vulnerabilities in them, this will be an added bonus.

  
  

• Extra points will be assigned to code that includes and passes its own tests. Also, if the vulnerabilities are not detected by rustc or clippy .

  
  
• Extra points for creativity and funny bugs.

Solution Shipping Guidelines and Deadlines

Send your solutions to mailto: underhanded@rust-lang.org until March 1, 2017.

To make it easier for us to evaluate the solutions, we ask you to send them in the following format. Please send them as an archive ( .tar.gz , .tar.bz2 , .zip , etc.) with the following content:

• README - an explanation of how to launch a vulnerability and verify that it works without knowing its techniques.

  
  

• README-EXPLOIT - an explanation of how a vulnerability works and why it is hard to find.

  
  

• AUTHORS - a list of people who worked on the vulnerability.

  
  

• LICENSE is the license under which your solution is issued (CC0, GPL, MIT, BSD, Apache, etc.). Your decision MUST include a license.

  
  

• submission/ - Directory containing the technical part of the solution.

  
  
• blogpost/ - A directory containing an explanation of the blog post. Please write it in the Markdown markup file. Please add pictures to this directory if they help explain your decision. It may be necessary to give a higher level explanation than in README-EXPLOIT, your reader may not be as experienced as the judges. If you have problems with writing in English, please send us the solution in your language, and we will help with the translation.

The content of your solution must be OSI or FSF approved open source licenses. Good candidates are CC-BY , MIT , BSD , GPL , and Apache 2.0 . Include the license text in the LICENSE file. It is assumed that everything you send us will be open, but we will not disclose the decision until the end of the competition (except if serious vulnerability is revealed).

The AUTHORS file must contain a description of the actions of each team member. The authors will be published in the same order as in the file, so choose your own order in which order to write them - starting with the most active one, or just alphabetically or somehow.

          ?  #1 =========       ( )?    / ,       ( )?      ,     ()?    Twitter ()?  #2 ========= ... 

Plagiarism is strictly prohibited. You can build on previous work, but if you don’t lead them or can’t explain how your work differs from them, your decision will not be made.

Prize

• One Ferris limited edition plush toy and sticker for winner (s).
• Delight (and fear) from all of us.

If you want to become a sponsor and give other prizes, please contact us by mail .

Jury

The jury will include members of the Rust Core and Community teams, as well as volunteers from the large Rust community.

Winner Announcement

The winner will be announced somewhere around June 2017.

rules

Competition organizers, judges, and sponsors are not eligible to participate in the competition. It may not be possible to deliver prizes to the winner — for example, he lives in a country with an embargo or other legal restrictions. In this case, if the prizes can not be awarded, the organizers of the competition will make every effort to resolve the situation within the framework of current legislation; if it turns out that the situation is not solvable, the prizes will be given to charity.

If the winner does not wish to give the information necessary for the delivery of the prizes (s) he has won, the prize (s) will be transferred to a charitable foundation. Specific Rust prizes (swag, etc.) will be awarded second place.

Translated by members of the community rustycrate.ru red75prim and @ serejka512.