Боюсь развести очередной флейм. Прежде чем сказать, почему мне до сих пор не очень приятно смотреть на эту библиотеку, скажу всё же несколько положительных слов.
1) Так, или иначе используя фунции С strcpy, …., printf программист аккуратно анализирует все возможные варианты уязвимостей – а выделил ли буфер, а достаточно ли этого буфера, а та ли на самом деле длина передаваемой строки, как я думаю, и т.д. В общем случае, конечно, удобно иметь свои «обёртки» стандартных функций С. Возможно ли сделать их раз и навсегда, длялюбыхпроектов? Не знаю. Но для похожих проектов, конечно, можно. Поэтому, рвение MS – “указать» на давно и всем известную проблему похвально. Дескать, помните…. Делайте, как мы.
2) Можно рассматривать библиотеку Microsoft strsafe как не самый плохой пример – как можно (или не нужно) делать. Скажу честно, я подсмотрел, как делают они. Нашёл некоторые идеи (скорее детали), и переписал свои реализации. Польза от этого есть, например, и на курсах по программированию, или на первых курсах … учебных и около учебных заведений. Это можно использовать, к примеру, на лабораторных работах. Короче, пример – он и есть пример. При этом студентам надо б говорить – это только пример, что и как надо учитывать в программировании.
3) Пример не самый плохой. Например, некоторые учебные материалы, где стоит, например, «клеймо» Сымантек, просто декларируют, рассказывают про уязвимости, не давая примеров реализаций «безопасных» функций. Эти, хоть что-то передрали и оформили в «библиотеку».
Теперь, что мне сильно не понравилось.
1) Одним словом можно сформулировать таким образом - крыша у них поехала. От собственного величия они даже не удосужились в анонсах сказать – а что это. Это безопасные функции, которые избавят, например, от срыва стека? Нет. Ну, так не говорят же! Говорят следующее:
“ … безопасно … бла-бла-бла … безопасно“…So check out Using the Strsafe.h Functions and enjoy…” “
Ладно, пытаюсь делать этот «enjoy»… Перед этим читаю, MSDN, что, к примеру, делает StringCchCopy.
StringCchCopy Function
--------------------------------------------------------------------------------
StringCchCopy is a replacement for strcpy. The size, in characters, of the destination buffer
is provided to the function to ensure that StringCchCopy does not write past the end of this buffer.
Syntax
HRESULT StringCchCopy( LPTSTR pszDest,
size_t cchDest,
LPCTSTR pszSrc
);
Parameters
pszDest
[out] Pointer to a buffer which receives the copied string.
cchDest
[in] Size of the destination buffer, in characters. This value must equal the length of pszSrc
plus 1 to account for the copied source string and the terminating null character.
The maximum number of characters allowed is STRSAFE_MAX_CCH.
pszSrc
[in] Pointer to a buffer containing the source string. This source string must be null-terminated.
Return Value
Note that this function returns an HRESULT as opposed to strcpy, which returns a pointer.
It is strongly recommended that you use the
SUCCEEDED and FAILED macros to test the return value of this function.
S_OK
Source data was present, fully copied without truncation, and the resultant
destination buffer is null-terminated.
STRSAFE_E_INVALID_PARAMETER
The value in cchDest is either 0 or larger than STRSAFE_MAX_CCH.
STRSAFE_E_INSUFFICIENT_BUFFER
The copy operation failed due to insufficient buffer space.
The destination buffer contains a truncated, null-terminated version of the intended result.
In situations where truncation is acceptable, this may not necessarily be seen as a failure condition.
Там функция и то анализирует и это анализирует, например, может возвратить
STRSAFE_E_INSUFFICIENT_BUFFER
The copy operation failed due to insufficient buffer space.
The destination buffer contains a truncated, null-terminated version of the intended result.
In situations where truncation is acceptable, this may not necessarily be seen as a failure condition.
Вот думаю, круто-то. На худой конец, функция просто «обрежет» буфер. Но я-то про это узнаю! Потом обработаю ситуацию! Ну, как написано в доке MSDN. Думаю, это технологии .NET они присабачили. Там всё безопасно для манагед байт-кода.
Затаив дыхание, набираю пример (с другого форума):
bool put_to_buf( const char *CameFromUserInput )
{
char buf[512];
return SUCCEEDED( StringCchCopy( (TCHAR *) buf, strlen(CameFromUserInput),(TCHAR *) CameFromUserInput ) );
}
Увы… Естественно, анализировать уже поздно… Смотрю, реализацию этой функции. Да - про переполнение мне расскажут. Но только вот пользы от этого не много. Поскольку вернёмся из put_to_buf, возможно, уже на код хакера.
2) Вместо того, чтобы писать безопасные функции, лучше б написали, а как эти пользоваться. Нет безопасных функций. Это безопасное программирование. Об этом надо было писать.
3) Написав то, что они написали – они ухудшили ситуацию. Прочитав ровно то, что написано в MSND – можно теперь пользоваться «безопасными» функциями. Что даёт это – см. выше.
4) Дав реализации, StrSafe.h они хотя бы написали, что аналогичные функции были уже давно написаны для Юникса. А так, получается, что они раскрыли глаза программистам.
5) Их деприкейтед – просто вывел из себя. Половина кода у народа не работает. Естественно правится быстро #define STRSAFE_NO_DEPRECATE. Но всё равно неприятно. Т.е. они думают, что найдётся идиот, и откажется от стандартной библиотеки?
6) После установки этого SDK у меня переписались на XP “пути”. Просто слёзы как SDK изуродовало систему. Теперь команды ping, tracert, как и много другое «отсутствуют». Очень безопасно. Типа, чтоб не пинговал зря никого.
Всё, что написано – сугубо моё мнение, которое я не навязываю, и доказывать не собираюсь.
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
