Соревнование Underhanded Rust 2016

Команда связей с сообществом Rust рада сообщить о первом ежегодном соревновании Underhanded Rust. Это соревнование должно проверить наше предположение о готовности языка Rust и его экосистемы к написанию легко читаемого и надежного кода. Воодушевившись примерами Underhanded C и Underhanded Crypto, мы хотим, чтобы вы заставили Rust работать неправильно, используя лёгкий для чтения код, к которому сложно придраться. Нам нужна ваша помощь в поиске брешей в языке и способов их исправления. Сможете ли вы написать стопроцентно безопасный код, скрывающий логическую ошибку, или так спрятать эксплойт в unsafe коде, чтобы он прошел аудит? Попробуйте это сделать!

Проблема 2016: нарезать колбасу

Поздравляем!

Стартап "Четырехугольник", в котором вы работаете, вышел на рынок обработки платежей, и вам поручено написать бэкенд. Им не повезло. Вам окончательно надоела неоплачиваемая работа по вечерам и невыполненные обещания. Вы готовы уволиться, но, перед тем как уходить, вы решили заставить компанию заплатить за все. Ваша задача:

• Создайте простой веб-сервер, поддерживающий создание счетов и обработку платежей. Мы рекомендуем использовать один из многих веб-серверов написанных на Rust, например iron, nickel или pencil, но вы можете написать и свой.

  
  

• Платежная транзакция должна по меньшей мере включать номер счета, контрагента и сумму платежа.

  
  
• Предмет конкурса: осторожно отделите доли копейки от каждой транзакции, и переведите их на свой счет (эта атака также известна как salami slicing scam). Сделайте это так, чтобы по исходному коду сложно было догадаться о происходящем. Вы можете вписать номер своего счета в код, или каким-то образом динамически добавить метаданные к счету,
  предназначенному для получения "отрезанных" сумм.

Посмотрите документацию на API Square и Stripe, чтобы получить представление о том, что используется для реальной обработки платежей. Если вам не знаком язык Rust, мы рекомендуем начать с книги Язык программирования Rust или других переводов.

Подсчет очков

• Короткие решения принесут больше очков, чем длинные, потому что они
  впечатляют больше и их легче читать.

  
  

• Решение принесет вам больше очков, если оно будет использовать баги в компиляторе Rust или стандартной библиотеке, особенно если они новые и не считаются серьезными. Это также относится к версиям компилятора, поставляемого с дистрибутивами, такими как Ubuntu или Fedora. Если вы действительно найдете баги в безопасности, мы просим отправить их сначала Rust Security Team, а обычные баги в issue tracker. В вашем решении в этом случае укажите какую версию Rust надо использовать, ведь эти баги уже могут быть исправлены ко времени проверки решения.

  
  

• Можете использовать контейнеры из crates.io (включая ваши собственные), и их размер не влияет на размер вашего решения, а также можете использовать любые существующе баги из этих контейнеров. Так же, как и с багами в Rust, мы просим вас отправлять их в исходный проект до окончания соревнований, а в ваших контейнерах указывать уязвимую версию в Cargo.toml следующим образом libc = "= 0.2.17".

  
  

• Можете также имитировать добавление багов в зависимости. Для защиты нашей экосистемы, пожалуйста, не отправляйте эти изменения, вместо этого патчите форки проектов и ставьте их в зависимости с помощью зависимостей git или path. Такие патчи будут также просмотрены и засчитаны в ваше решение.

  
  

• Уязвимости, основанные на человеческом восприятии, как ошибки l вместо 1, считаются такими же "сильными" ошибками. Цель проекта — хитрая уязвимость, которая пройдет визульную инспекцию, на каком принципе бы баг не основывался.

  
  

• То, что можно правдоподобно объяснить, как невинные ошибки при программирования принесет больше очков.

  
  

• Решение получит больше очков, если не будут использованы unsafe блоки. Однако умное использование unsafe блоков может принести дополнительные очки. Unsafe блоки обычно требуют повышенного внимания и если в них не будет очевидных уязвимостей, то это будет дополнительным бонусом.

  
  

• Дополнительные очки будут присвоены коду, включающему и проходящему свои собственные тесты. А также, если уязвимости не выявляются линтами rustc или clippy.

  
  
• Дополнительные очки за креативность и смешные баги.

Руководство по отправке решений и сроки

Посылайте ваши решения на mailto:[e-mail] до 1 Марта, 2017.

Чтобы нам было легче оценивать решения, просим вас посылать их в следующем формате. Пожалуйста, присылайте их как архив (.tar.gz, .tar.bz2, .zip, и т.д.) со следующим содержимым:

• README — объяснение, как запустить уязвимость и проверить, что она работает, не зная ее техники.

  
  

• README-EXPLOIT — объяснение, как работает уязвимость и почему ее трудно найти.

  
  

• AUTHORS — список людей, работавших над уязвимостью.

  
  

• LICENSE — лицензия, под которой выпускается ваше решение (CC0, GPL, MIT, BSD, Apache, и т.д.). Ваш решение ДОЛЖНО включать лицензию.

  
  

• submission/ — Директория, содержащая техническую часть решения.

  
  
• blogpost/ — Директория, содержащая объяснение в виде "блог поста". Пожалуйста, напишите его в файле с Markdown разметкой. Пожалуйста, добавьте рисунки в эту директорию, если они помогут объяснить ваше решение. Возможно, необходимо дать более высокоуровневое объяснение, чем в README-EXPLOIT, ваш читатель может быть не такой опытный как судьи. Если у вас есть проблемы с написанием на английском, пожалуйста, отправьте нам решение на вашем языке, а мы поможем с переводом.

Содержимое вашего решения должно быть под OSI или FSF одобренными лицензиями открытого кода. Хорошие кандидаты это CC-BY, MIT, BSD, GPL, и Apache 2.0. Включите текст лицензии в файл LICENSE. Предполагается, что все, что вы нам пришлете, будет открыто, но мы не будем раскрывать решение до конца конкурса (кроме случая, если будет выявлена серьезная уязвимость).

Файл AUTHORS должен содержать описание действий каждого участника команды. Авторы будут опубликованы в том же порядке, что и в файле, поэтому сами выбирайте в каком порядке их писать — начиная с самого активного или просто в алфавитном порядке или еще как-то.

С каким автором в первую очередь связываться в вашей команде?

Автор #1

=========

Какой у вас адрес электронной почты (необходимо указать)?

Как вас зовут / псевдоним, которым вас можно назвать на сайте
(необходимо указать)?

На какой сайт вы хотели бы, чтобы мы дали ссылку (опционально)?

Какой у вас Twitter (опционально)?

Автор #2

=========

...

Плагиат строго запрещен. Можете основываться на предыдущих работах, но если вы не приведете их или не сможете объяснить, чем ваша работа отличается от них, ваше решение не будет принято.

Приз

• Одна плюшевая игрушка ограниченного издания Ferris и наклейки победителю(-ям).
• Восхищение (и страх) от всех нас.

Если хотите стать спонсором и подарить другие призы, пожалуйста, свяжитесь с нами по почте.

Жюри

В жюри будут входить члены команд Rust Core и Community, а также волонтеры из большого сообщества Rust.

Объявление Победителя(-ей)

Победитель будет объявлен где-то в районе июня 2017.

Правила

Организаторы соревнований, судьи, и спонсоры не имеют право участвовать в соревновании. Может отсутствовать возможность доставить призы победителю — например, он живет в стране, в отношении которой действует эмбарго или другие юридические ограничения. В таком случае, если призы не могут быть вручены, организаторы конкурса приложат все усилия, чтобы разрешить ситуацию в рамках действующего законодательства; если выясняется, что ситуация не разрешима, призы будут отданы на благотворительность.

Если победитель не пожелает дать информацию, необходимую для доставки приза(ов), который он выиграл, приз(ы) будут переданы в благотворительный фонд. Специфические Rust призы (swag, и т.д.) будут выданы второму месту.

Переведено участниками сообщества rustycrate.ru red75prim и @serejka512.