Я работаю над функцией C getCredentials
и обнаружил флаг Checkmarx относительно переменной lpass
. Однако, насколько я понимаю, и lid
, и lpass
хранятся локально в стеке внутри функции.
void getCredentials(char *id, char *pass) {
char lid[userid_size];
char lpass[pwd_size]; // Flagged in Checkmarx
strncpy(lid, id, userid_size);
strncpy(lpass, pass, pwd_size);
// dbconnect(&dbstruct, lpass, lid);
}
Может ли кто-нибудь объяснить, почему Checkmarx помечает lpass
для проверки кучи, и является ли это ложным срабатыванием или есть потенциальная проблема, которую я упускаю из виду?
Переполнение буфера может произойти и здесь. Помните о терминаторе NUL и не забывайте проверять коды ошибок функций, которые могут выйти из строя.
Меня особенно беспокоит уязвимость проверки кучи: все функции strncpy помечены как buffer_overflow.
Зачем вообще делать копию, если все, что вы делаете, это передаете значения dbconnect()
?
Если pwd_size
является переменной, то размер массива может быть переменным, и реализация может разместить его в куче (вероятно, нет, но вы не можете сказать 100%). Может быть, это все?
Пожалуйста, укажите точное диагностическое сообщение, выданное Checkmarx.
Уязвимость проверки кучи отмечена до или после функций strncpy()
? Если он помечен позже, это может быть ложное срабатывание, вызванное функциями strncpy()
. Если это было отмечено ранее, вероятно, это не ложное срабатывание, вызванное функциями strncpy()
. Будет ли это по-прежнему ложным срабатыванием, зависит от того, что Checkmarx подразумевает под «уязвимостью проверки кучи». Стоит исправить strncpy()
проблемы и провести повторное тестирование. Зачем копировать то, что передается в функцию подключения? Почему бы не убедиться, что строки завершаются нулем? Есть ли еще проблема без strncpy()
?
@JonathanLeffler перед передачей строки в dbconnect происходит множество логических действий. Я пропустил эти строки, поскольку они не имели отношения к проверке кучи.
«Инспекция кучи» касается конфиденциальной информации, хранящейся в памяти машины в незашифрованном виде. Где именно он хранится, совершенно не важно.
Любая копия конфиденциальной информации должна быть уничтожена, как только она больше не нужна. В противном случае злоумышленник, имеющий доступ только для чтения к памяти процесса, может проверить ее и найти конфиденциальные данные. потенциально она может пережить освобождение, смерть процесса и последующее выделение этой памяти другим процессом, где ее можно будет проверить.
Если вам нужно временно сохранить незашифрованную копию пароля, обнулите ее, как только закончите с ней. Это снижает риск, а не устраняет его полностью. Последнее невозможно при данной модели атаки, поскольку нарушение уже произошло и злоумышленник имеет некоторый уровень доступа. Если ему повезет, он найдет незашифрованную информацию именно в тот краткий момент, когда она существует.
Это не совсем моя область знаний. Пусть покупатель будет бдителен.
Возможно, ОТ: вы, вероятно, неправильно используете
strncpy
. Прочтите внимательно документациюstrncmp
, это не более безопасная версияstrcpy
.