random technical notes

Snowden’s Beloved Tails OS Reaches v1.0 Milestone.

Yesterday (22 Feb, 2014), Apple pushed a rather spooky security update for iOS that suggested that something was horribly wrong with SSL/TLS in iOS but gave no details. Since the answer is at the top of the Hacker News thread, I guess the cat’s out of the bag already and we’re into the misinformation-quashing stage now.

more

Additional: goto fail and embedded C Compilers

• ООП (и его реализация на С++) хорошо подходит для неоднородной команды, когда надо создавать ограничения на использование данных (объектов), чтобы более слабые программисты не натворили больших бед.
• бездумное использование выделения памяти (операторы new/delete) и умных указателей – показатель не очень хорошей архитектуры. Если в API функции сказано, что надо за собой удалять объект (структуру), так будь любезен не ленись, а то напридумали всякие «помойки памяти» (garbage collection) для ленивых.
  • использование «умных указателей» может быть накладным: Smart Pointer Timings.  При этом класс «умный указатель» должен переопределить многие операторы (например, operator*(), operator=() и так далее) и тогда простая операция на самом деле будет не такой простой:
    smart1->setValue(smart2->getValue());
    При этом всё-таки надо проверять на наличие объекта (if(true == smart1.healthy())), так как возможна ситуация, когда кто-нибудь напишет так: smart1= NULL;
  • уж лучше использовать идею заложенную в IUnknown интерфейсе, когда для подсчёта ссылок используются явно вызываемые методы AddRef() и Release() (конструктор и деструктор у такого класса объявлены защищёнными, что предотвращает неправильный вызов операторов new/delete для этого класса)
  • бездумное объявление виртуальных функций тоже добавляет дополнительные расходы на доступ к методам класса. Смотри презентацию “Virtual Functions“. Для уменьшения накладных расходов, Microsoft даже добавила специальный атрибут при объявлении интерфейсов: __declspec(novtable).
• При декларации класса на языке C++ необходимо помнить о правиле «большая тройка».
  • При этом не очень подготовленные программисты забывают, что хоть класс состоит из методов и данных, но всё-таки это отдельные сущности и при создании класса память выделяется только для данных.
• как минимум «простые» приложения можно описать используя парадигму конечного автомата (state machine) – есть состояние программы, которое можно узнать проверяя значения переменных через функции и есть переходы от одного состояния в другое, при этом тип состояния можно легко узнать.
• Графический интерфейс пользователя вообще неправильно разрабатывать используя объекты. Есть примитивы (могут быть и свои контролы). Есть состояния этих примитивов и переходы. Но в навороченных приложениях создают такую объектную модель, что два соседних контрола не могут взаимодействовать друг с другом напрямую и всё взаимодействие идёт через уровень логики.
  • как вариант, Qt версии 4.6 реализован State Machine Framework.
• Даже временные данные можно хранить в SQLite (надо проверить быстродействие) и тогда доступ к данным может быть осуществлён глобально, нет проблем с многопоточностью так как SQLite потокобезопасен и при этом сериализация может быть достигнута довольно простой операцией сохранения таблицы в файл.
• Исключения ещё хуже чем бездумное выделение памяти – стэк забивают (так как нужно обрабатывать раскрутку исключения), а так же нарушают логику работы.
• Про мультипоточное программирование вообще молчу. Для многих это сложно.

Note: This paper is derived from the book The Security Development Lifecycle, by Michael Howard and Steve Lipner, Microsoft Press, 2006.

Prohibiting the use of banned APIs is a good way to remove a significant number of code vulnerabilities — this practice is reflected in Stage 6 of The Microsoft Security Development Lifecycle: “Establish and Follow Best Practices for Development.” It can also be referenced in Chapter 11 of the Microsoft Press Book The Security Development Lifecycle.

When the C runtime library (CRT) was first created about 25 years ago, the threats to computers were different; machines were not as interconnected as they are today, and attacks were not as prevalent. With this in mind, a subset of the C runtime library must be deprecated for new code and, over time, removed from earlier code. It’s just too easy to get code wrong that uses these outdated functions. Even some of the classic replacement functions are prone to error, too.

This list is the SDL view of what comprises banned APIs; it is derived from experience with real-world security bugs and focuses almost exclusively on functions that can lead to buffer overruns (Howard, LeBlanc, and Viega 2005). Any function in this section’s tables must be replaced with a more secure version. Obviously, you cannot replace a banned API with another banned API. For example, replacing strcpy with strncpy is not valid because strncpy is banned, too.

Also note that some of the function names might be a little different, depending on whether the function takes ASCII, Unicode, _T (ASCII or Unicode), or multibyte chars. Some function names might include A or W at the end of the name. For example, the StrSafe StringCbCatEx function is also available as StringCbCatExW (Unicode) and StringCbCatExA (ASCII).

More info