информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле ЛевинаВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Утекший код XP и Windows Server... 
 Дела виртуальные 
 Простое пробивание рабочего/провайдерского... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Большая. И написали очень двусмысленно. 01.04.05 21:14  Число просмотров: 1724
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
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.

Одно дело когда этот параметр 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.


В первом случае он означает размер буфера КУДА строка будет копироваться, что позволит функции не допустить записи в тот буфер больше заданного тут количества символов, другое дело когда он равен длине копируемой строки + 1 символ (как у тебя в коде), в этом случае этот параметр вообще бессмысленен.
<programming>
[C++] StrSafe 25.03.05 18:11  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Отстал от жизни ...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/strsafe.asp
Как давно это появилось? Кто юзает? Поделитесь впечатлениями. Какие лимитэйшн?

На фоне общей разрухи очень даже приятно. Следующий шаг у них думаю будет - изъятие у стандартного программиста стандартных библиотек вообще. ;))
Ответов было не очень много. Решил убедиться сам в том, что... 29.03.05 04:44  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Ответов было не очень много. Решил убедиться сам в том, что там они напридумали... Не поленился, поставил XP SDK. Посмотрел, что делает, например, StringCchCopy функция. Дас, всякого ожидал... Но такого. :)))
Библиотека полный отстой (да простят меня модераторы за грубое слово).
Вообще от MS такого не ожидал...
Рассказал бы поподробнее? 01.04.05 03:36  
Автор: AlexD <Alexander> Статус: Member
<"чистая" ссылка>
Моё мнение 01.04.05 08:41  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Боюсь развести очередной флейм. Прежде чем сказать, почему мне до сих пор не очень приятно смотреть на эту библиотеку, скажу всё же несколько положительных слов.

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, как и много другое «отсутствуют». Очень безопасно. Типа, чтоб не пинговал зря никого.

Всё, что написано – сугубо моё мнение, которое я не навязываю, и доказывать не собираюсь.
Не знаю, что у тебя там с установкой SDK - ни разу не было проблем с путями. 15.04.05 13:53  
Автор: AlexD <Alexander> Статус: Member
<"чистая" ссылка>
А может надо было так писать Ж) - 01.04.05 11:17  
Автор: Killer{R}_ Статус: Незарегистрированный пользователь
<"чистая" ссылка>
А может надо было так писать Ж) -
bool put_to_buf( const char *CameFromUserInput )
{
char buf[512];

return SUCCEEDED( StringCchCopy( (TCHAR *) buf,512,(TCHAR *) CameFromUserInput ) );
}

А сочинители МСДН описали функцию загадочно очень, особенно второй параметр)
А какая разница. Недвусмыслено они написали, что.... 01.04.05 17:26  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> А может надо было так писать Ж) -
> bool put_to_buf( const char *CameFromUserInput )
> {
> char buf[512];
>
> return SUCCEEDED( StringCchCopy( (TCHAR *)
> buf,512,(TCHAR *) CameFromUserInput ) );
> }
>
> А сочинители МСДН описали функцию загадочно очень, особенно
> второй параметр)
А какая разница. Недвусмыслено они написали, что ... результват будет такой-то и такой-то.
Большая. И написали очень двусмысленно. 01.04.05 21:14  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
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.

Одно дело когда этот параметр 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.


В первом случае он означает размер буфера КУДА строка будет копироваться, что позволит функции не допустить записи в тот буфер больше заданного тут количества символов, другое дело когда он равен длине копируемой строки + 1 символ (как у тебя в коде), в этом случае этот параметр вообще бессмысленен.
В файле StrSafe.h (там реализация лежит, посмотри) всё... 01.04.05 21:43  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Одно дело когда этот параметр Size of the destination
> buffer, in characters.

В файле StrSafe.h (там реализация лежит, посмотри) всё написано - где байты, а где символы.


> И совсем другое когда он (как ты и понял) This value must
> equal the length of pszSrc
> plus 1 to account for the copied source string and the
> terminating null character.

Продекларировано, что фунция будет работать при любых обстоятельствах. Ну, так я об этом.

> В первом случае он означает размер буфера КУДА строка будет
> копироваться, что позволит функции не допустить записи в
> тот буфер больше заданного тут количества символов, другое
> дело когда он равен длине копируемой строки + 1 символ (как
> у тебя в коде), в этом случае этот параметр вообще
> бессмысленен.

Не смеши меня. Достаточно стандартной библиотеки. Там ведь не одна только strcpy?
Как мы сами пишем разные функции, позволяющие выполнять дополнительный контроль, так и они предложили свои. Для моих нужд мне достаточно своих. Ничего принципиально нового в strsafe.h нет. Я пытался показать - ТО, ЧТО ПРОДЕКЛАРИРОВАНО MS В MSDN относительно StrSafe.h и в части повышения безопасности - не соответствует дйствительности с моей точки зрения.
Нет у меня этого файла. 01.04.05 21:53  
Автор: Killer{R} <Dmitry> Статус: Elderman
<"чистая" ссылка>
> > Одно дело когда этот параметр Size of the destination
> > buffer, in characters.
>
> В файле StrSafe.h (там реализация лежит, посмотри) всё
> написано - где байты, а где символы.
Нет у меня этого файла.


> > И совсем другое когда он (как ты и понял) This value
> must
> > equal the length of pszSrc
> > plus 1 to account for the copied source string and the
> > terminating null character.
>
> Продекларировано, что фунция будет работать при любых
> обстоятельствах. Ну, так я об этом.
Она ПРИНЦИПИАЛЬНО не может работать при любых обстоятельствах. Я думаю там просто опечатались во втором предложении описания второго параметра.

> Не смеши меня. Достаточно стандартной библиотеки. Там ведь
> не одна только strcpy?
Да есть и безопасные функции strncpy. Но они не завершают строку нулевым символом в том случае если она длиннее предоставленного буфера. А StrSafe - завершает. В этом насколько я понял ее единственное отличие от strncpy.
Я не защищаю создателей StrSafe - я ее никогда не юзал и юзать не хочу. Я в данном случае объясняю где ты мог ошибится. Принципиальный подход "Все это маздай" тоже не луший способ. Альтернатива всегда полезна.

> в strsafe.h нет. Я пытался показать - ТО, ЧТО
> ПРОДЕКЛАРИРОВАНО MS В MSDN относительно StrSafe.h и в части
> повышения безопасности - не соответствует дйствительности с
> моей точки зрения.
В мсдн похоже просто опечатка.
моё мыло vg_123 собака@ mail.ru. Могу тебе переправить. 01.04.05 22:19  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>

> Нет у меня этого файла.

моё мыло vg_123 собака@ mail.ru. Могу тебе переправить.

> Я не защищаю создателей StrSafe - я ее никогда не юзал и
> юзать не хочу. Я в данном случае объясняю где ты мог
> ошибится.

Без издёвки - спасибо. Я ошибаюсь часто.

>Принципиальный подход "Все это маздай" тоже не
> луший способ. Альтернатива всегда полезна.

Жаль если ты так прочитал мой пост. Никогда не говорил и не разделял взгляды "маздай".

> В мсдн похоже просто опечатка.

У меня и у тебя могут быть опечатки. Для MS - это слишком. Тем более, что это ещё с 2000 года, судя по всему висит (народ юзал, как оказалась раньше 2002 года). Это их вера и самомнение в непогрешимость.

ПС.
1) Если ты посмотришь, те сорцы, то увидишь, что функции будут продолжать копировать в буфер, переполняя его. "Опомнятся" они и вернут соответствующий код ошибки потом. Но уже поздно.

2) Полезного там две вещи:

2.1) Они напомнили программерам (и разделили это в своей библиотеке), что считать надо не только байты, но и символы строк.

2.2) сделали это (разделили) для уникода и мультибайта.

(хотя про юникод в понимании MS без боли в сердце тоже не могу говорить)
нашел в инете 01.04.05 23:35  
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 01.04.05 23:42  Количество правок: 2
<"чистая" ссылка>
ссылка - http://csislabs.palomar.edu/Student/Directx9.0/dx9sdk/Include/strsafe.h
Смотрим сырцы:
StringCchCopy является враппером для StringCopyWorkerA

StringCopyWorkerA в свою очередь написан вполне корректно и переполнения не получится если cchDest - это размер буфера КУДА ПРОИЗВОДИТСЯ ЗАПИСЬ. То бишь - размер pszDest. Функция как и предполалось полностью идентична strncpy за исключением гарантированного обнуления последнего символа строки.

В коментах StringCchCopy написано:
cchDest - size of destination buffer in characters.
length must be = (_tcslen(src) + 1) to hold all of the
source including the null terminator
То бишь имелось ввиду что для того чтобы строка была переписана полностью размер буфера pszDest должен быть (_tcslen(src) + 1). Ну и соответственно параметр cchDest, показывающий размер буфера таким будет. Но это значит что надо выделить память под pszDest столько а не просто передать такой cchDest.

А вот те кто писали МСДН написали уже так:
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.
То есть случай как с запятой - казнить нельзя помиловать. Смысл перевран полнстью от небольшой перефразировки тех кто писал статью мсдн по комментам из сырцов. Напишите ктонить Биллу Гейтсу чтоб исправили, а то скоро все компутерно-популярные издания начнут пестреть заголовками что МС облажались (хотя в какой то степени оно так и есть Ж))

btw - сам факт наличия реализации функции в хедере тоже очень прикалывает Ж)
That was my point. 02.05.05 20:49  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> что МС облажались (хотя в какой то степени оно так и есть
> Ж))

That was my point.

>
> btw - сам факт наличия реализации функции в хедере тоже
> очень прикалывает Ж)

No offense. There is a macro about the "lib" version of the library.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach