Bonjour;
Note: j'ai pris ma retraite de JKA il y a longtemps (plusieurs années...). Ça ne m'empêche pas de continuer à répondre à une question de temps en temps, mais il ne faut pas compter sur moi pour publier des patches.
yberion wrote:Et si tu pouvais me donner le code corriger de la faille ( juste les lignes qu'il faut ) pour le sdk pour basejk ça serai sympa.
La vraie faille n'est pas dans le SDK, elle est dans le serveur, qui est closed-source.
Le code correspondant dans un serveur Quake 3 est:
Code: Select all
void Cvar_Update( vmCvar_t *vmCvar ) {
cvar_t *cv = NULL; // bk001129
assert(vmCvar); // bk
if ( (unsigned)vmCvar->handle >= cvar_numIndexes ) {
Com_Error( ERR_DROP, "Cvar_Update: handle out of range" );
}
cv = cvar_indexes + vmCvar->handle;
if ( cv->modificationCount == vmCvar->modificationCount ) {
return;
}
if ( !cv->string ) {
return; // variable might have been cleared by a cvar_restart
}
vmCvar->modificationCount = cv->modificationCount;
// bk001129 - mismatches.
if ( strlen(cv->string)+1 > MAX_CVAR_VALUE_STRING )
Com_Error( ERR_DROP, "Cvar_Update: src %s length %d exceeds MAX_CVAR_VALUE_STRING",
cv->string,
strlen(cv->string),
sizeof(vmCvar->string) );
// bk001212 - Q_strncpyz guarantees zero padding and dest[MAX_CVAR_VALUE_STRING-1]==0
// bk001129 - paranoia. Never trust the destination string.
// bk001129 - beware, sizeof(char*) is always 4 (for cv->string).
// sizeof(vmCvar->string) always MAX_CVAR_VALUE_STRING
//Q_strncpyz( vmCvar->string, cv->string, sizeof( vmCvar->string ) ); // id
Q_strncpyz( vmCvar->string, cv->string, MAX_CVAR_VALUE_STRING );
vmCvar->value = cv->value;
vmCvar->integer = cv->integer;
}
Comme derrière la copie est bornée par MAX_CVAR_VALUE_STRING, ça ne devrait pas poser problème de désactiver l'instruction Com_Error(...), ou de la remplacer par un simple avertissement. Malheureusement, encore une fois on n'a pas les sources pour faire ça.
Ça ne veut pas dire que ce soit impossible à faire, mais si on veut procéder de cette manière, il faut le faire en assembleur, directement sur l'exécutable du serveur. Ce serait du ressort de Luigi. D'ailleurs il a fait des patches de ce type pour CoD il me semble.
Note: la commande callvote est ici
http://www.mt-wudan.com/jkamp/g__cmds_8c.html#a51
L'appel au serveur pour la récupération des arguments est ici:
Code: Select all
01916 trap_Argv( 1, arg1, sizeof( arg1 ) );
01917 trap_Argv( 2, arg2, sizeof( arg2 ) );
Pusique tu dis que désactiver le vote évite le crash, ça signifie que
Code: Select all
01892 if ( !g_allowVote.integer ) {
01893 trap_SendServerCommand( ent-g_entities, va("print \"%s\n\"", G_GetStringEdString("MP_SVGAME", "NOVOTE")) );
01894 return;
01895 }
s'exécute *avant* Update. Donc
hypothétiquement, on pourrait tester la longueur de l'argument avant les trapcalls. Mais en fait ça ne nous aide pas parce que les arguments sont traités dans le serveur, on peut juste les récupérer. On n'a pas accès au buffer avant le traitement par Update. A moins qu'il existe un trapcall qui renvoie le buffer tel-quel, mais je n'ai pas l'impression que ce soit le cas.
Tout ça pour dire que -- à première vue -- je ne pense pas qu'il soit possible de régler le problème par un mod (ie. jampgame), mais que ça relève d'un patch pour le serveur (jampgame, donc pas de source).
Voilà. Tu es bien sûr encouragé à demander une seconde opinion à qqn qui n'est pas en retraite.
