Chat global
Práticas Seguras - Parte 01
Fala Galera.
Queria mostrar uma parada simples, porém bem útil e que vi em praticamente TODAS as sources vazadas não possuem.
Essa é a Parte 01, um pequeno começo e quem sabe mais pra frente resolvo fazer mais partes.
(Lembrando, não sou Dev, apenas um camarada com curiosidade que corre atras para tentar entender tudo, caso exista algum erro, por favor, me corrijam 🙂 )
Bom, vamos lá.
Vou usar de exemplo a função InitField()
int InitField()
{
int cnt;
lstrcpy(szFieldDirectory, "field\\");
lstrcpy(szMapDirectory, "field\\map\\");
lstrcpy(szTitleDirectory, "field\\title\\");
ZeroMemory(sField, sizeof(sFIELD) * FIELD_MAX);
for (cnt = 0; cnt < FIELD_MAX; cnt++)
sField[cnt].FieldCode = cnt;
}
o Uso de lstrcpy é PERIGOSO! ele copia a string (ex: szFieldDirectory) e não sabe o tamanho dela.
o quão perigoso é isso? Isso significa que, se no futuro o conteúdo copiado for maior do que o espaço disponível, o código pode causar o famoso buffer overflow e outras coisas.
Então, por que substituir por strcpy_s?
basicamente, usando strcpy_s, o tamanho do destino é explicito. Sendo assim, caso ele ultrapasse esse valor, ele não copia a string e sinaliza o erro. (o cara é foda patrão.)
Depois de muito bla, bla, bla, como ficaria essa função corrigida então meus nobres?
Assim:
int InitField()
{
int cnt;
strcpy_s(szFieldDirectory, sizeof(szFieldDirectory), "field\\");
strcpy_s(szMapDirectory, sizeof(szMapDirectory), "field\\map\\");
strcpy_s(szTitleDirectory, sizeof(szTitleDirectory), "field\\title\\");
ZeroMemory(sField, sizeof(sFIELD) * FIELD_MAX);
for (cnt = 0; cnt < FIELD_MAX; cnt++)
sField[cnt].FieldCode = cnt;
return 0;
}
Bom, foi isso.
Talvez traga mais coisas basicas que estou aprendendo para melhorias, porém me falta TEMPO.
Tmj.
Postado por: @datwayFala Galera.
Queria mostrar uma parada simples, porém bem útil e que vi em praticamente TODAS as sources vazadas não possuem.
Essa é a Parte 01, um pequeno começo e quem sabe mais pra frente resolvo fazer mais partes.
(Lembrando, não sou Dev, apenas um camarada com curiosidade que corre atras para tentar entender tudo, caso exista algum erro, por favor, me corrijam 🙂 )
Bom, vamos lá.
Vou usar de exemplo a função InitField()
int InitField() { int cnt; lstrcpy(szFieldDirectory, "field\\"); lstrcpy(szMapDirectory, "field\\map\\"); lstrcpy(szTitleDirectory, "field\\title\\"); ZeroMemory(sField, sizeof(sFIELD) * FIELD_MAX); for (cnt = 0; cnt < FIELD_MAX; cnt++) sField[cnt].FieldCode = cnt; }o Uso de lstrcpy é PERIGOSO! ele copia a string (ex: szFieldDirectory) e não sabe o tamanho dela.
o quão perigoso é isso? Isso significa que, se no futuro o conteúdo copiado for maior do que o espaço disponível, o código pode causar o famoso buffer overflow e outras coisas.
Então, por que substituir por strcpy_s?
basicamente, usando strcpy_s, o tamanho do destino é explicito. Sendo assim, caso ele ultrapasse esse valor, ele não copia a string e sinaliza o erro. (o cara é foda patrão.)
Depois de muito bla, bla, bla, como ficaria essa função corrigida então meus nobres?
Assim:
int InitField() { int cnt; strcpy_s(szFieldDirectory, sizeof(szFieldDirectory), "field\\"); strcpy_s(szMapDirectory, sizeof(szMapDirectory), "field\\map\\"); strcpy_s(szTitleDirectory, sizeof(szTitleDirectory), "field\\title\\"); ZeroMemory(sField, sizeof(sFIELD) * FIELD_MAX); for (cnt = 0; cnt < FIELD_MAX; cnt++) sField[cnt].FieldCode = cnt; return 0; }Bom, foi isso.
Talvez traga mais coisas basicas que estou aprendendo para melhorias, porém me falta TEMPO.
Tmj.
é por aí que acontecem a maioria dos ataques para derrubar servidores, o problema não é o tamanho do buffer em si, mas o modo como a função lida com esses dados, lstrcpy (existem outras funções também...) necessita de um terminador nulo \0 para saber onde termina a string que ela está copiando.
ou seja, se passar uma string maior que o buffer e nunca dizermos onde está o terminador nulo, ela vai continuar copiando e lendo dados na memoria além do buffer, isso faz com que a função copie dados de locais da memoria que não deveria, crashando o processo.
lstrcpy foi descontinuada em 2002 eu acho, tem diversos cves disso na web, é só pesquisar:
https://github.com/moonlight-stream/moonlight-common-c/security/advisories/GHSA-r8cf-45f4-vf8m
https://www.gamedev.net/forums/topic/292771-lstrcpy-marked-as-pragma-deprecated/
@edit
inclusive o próprio compilador alerta isso quando a gente tenta compilar algo usando lstrcpy :
Gravidade Código Descrição Projeto Arquivo Linha Estado de Supressão Detalhes Erro C4996 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
1 por amor, 2 por dinheiro
@vigo isso ai meu camarada! se a pessoa ler um pouco e pesquisar, vai ver que o compilador diz na cara dela: CORREGE ISSO AI MEU FÍ.
foi por causa disso que eu fui atras pra tentar entender.
Obrigado pelo complemento.
- 21 Fóruns
- 290 Tópicos
- 1,726 Posts
- 10 Online
- 316 Membros
