int a;
char const *s = "Hello world";
printf("%s%nn", s, &a);
Seulement une autre personne également sous MinGW compile ce code, et
il semble que le spécificateur %n est ignoré. : si on initialise l a
variable a avec une valeur quelconque, on retrouve cette valeur après
l'appel de printf.
int a;
char const *s = "Hello world";
printf("%s%nn", s, &a);
Seulement une autre personne également sous MinGW compile ce code, et
il semble que le spécificateur %n est ignoré. : si on initialise l a
variable a avec une valeur quelconque, on retrouve cette valeur après
l'appel de printf.
int a;
char const *s = "Hello world";
printf("%s%nn", s, &a);
Seulement une autre personne également sous MinGW compile ce code, et
il semble que le spécificateur %n est ignoré. : si on initialise l a
variable a avec une valeur quelconque, on retrouve cette valeur après
l'appel de printf.
On 26 fév, 07:16, GurneyH wrote:
> int a;
> char const *s = "Hello world";
> printf("%s%nn", s, &a);
Ne fonctionne pas chez moi (MinGW).
> Seulement une autre personne également sous MinGW compile ce code, et
> il semble que le spécificateur %n est ignoré. : si on initialise la
> variable a avec une valeur quelconque, on retrouve cette valeur après
> l'appel de printf.
Il me semble que "%n" n'est définit que pour scanf(). Je vérifie ...
On 26 fév, 07:16, GurneyH <Gurn...@neuf.fr> wrote:
> int a;
> char const *s = "Hello world";
> printf("%s%nn", s, &a);
Ne fonctionne pas chez moi (MinGW).
> Seulement une autre personne également sous MinGW compile ce code, et
> il semble que le spécificateur %n est ignoré. : si on initialise la
> variable a avec une valeur quelconque, on retrouve cette valeur après
> l'appel de printf.
Il me semble que "%n" n'est définit que pour scanf(). Je vérifie ...
On 26 fév, 07:16, GurneyH wrote:
> int a;
> char const *s = "Hello world";
> printf("%s%nn", s, &a);
Ne fonctionne pas chez moi (MinGW).
> Seulement une autre personne également sous MinGW compile ce code, et
> il semble que le spécificateur %n est ignoré. : si on initialise la
> variable a avec une valeur quelconque, on retrouve cette valeur après
> l'appel de printf.
Il me semble que "%n" n'est définit que pour scanf(). Je vérifie ...
> On 26 fév, 10:13, -ed- wrote:
> On 26 fév, 07:16, GurneyH wrote:
> > int a;
> > char const *s = "Hello world";
> > printf("%s%nn", s, &a);
> Ne fonctionne pas chez moi (MinGW).
> > Seulement une autre personne également sous MinGW compile ce code, et
> > il semble que le spécificateur %n est ignoré. : si on initiali se la
> > variable a avec une valeur quelconque, on retrouve cette valeur apr ès
> > l'appel de printf.
> Il me semble que "%n" n'est définit que pour scanf(). Je vérifie .. .
Effectivement, c'est aussi pour [f]printf()
WG14/N1256 Committee Draft September 7, 2007 ISO/IEC 9899:TC3
7.19.6.1
n The argument shall be a pointer to signed integer into which is
written the
number of characters written to the output stream so far by this call
to
fprintf. No argument is converted, but one is consumed. If the
conversion
specification includes any flags, a field width, or a precision, the
behavior is
undefined.
Mais curieusement, je confirme que ça ne fonctionne pas avec MinGW
sous Vista SP2.
> On 26 fév, 10:13, -ed- <emmanuel.delah...@gmail.com> wrote:
> On 26 fév, 07:16, GurneyH <Gurn...@neuf.fr> wrote:
> > int a;
> > char const *s = "Hello world";
> > printf("%s%nn", s, &a);
> Ne fonctionne pas chez moi (MinGW).
> > Seulement une autre personne également sous MinGW compile ce code, et
> > il semble que le spécificateur %n est ignoré. : si on initiali se la
> > variable a avec une valeur quelconque, on retrouve cette valeur apr ès
> > l'appel de printf.
> Il me semble que "%n" n'est définit que pour scanf(). Je vérifie .. .
Effectivement, c'est aussi pour [f]printf()
WG14/N1256 Committee Draft September 7, 2007 ISO/IEC 9899:TC3
7.19.6.1
n The argument shall be a pointer to signed integer into which is
written the
number of characters written to the output stream so far by this call
to
fprintf. No argument is converted, but one is consumed. If the
conversion
specification includes any flags, a field width, or a precision, the
behavior is
undefined.
Mais curieusement, je confirme que ça ne fonctionne pas avec MinGW
sous Vista SP2.
> On 26 fév, 10:13, -ed- wrote:
> On 26 fév, 07:16, GurneyH wrote:
> > int a;
> > char const *s = "Hello world";
> > printf("%s%nn", s, &a);
> Ne fonctionne pas chez moi (MinGW).
> > Seulement une autre personne également sous MinGW compile ce code, et
> > il semble que le spécificateur %n est ignoré. : si on initiali se la
> > variable a avec une valeur quelconque, on retrouve cette valeur apr ès
> > l'appel de printf.
> Il me semble que "%n" n'est définit que pour scanf(). Je vérifie .. .
Effectivement, c'est aussi pour [f]printf()
WG14/N1256 Committee Draft September 7, 2007 ISO/IEC 9899:TC3
7.19.6.1
n The argument shall be a pointer to signed integer into which is
written the
number of characters written to the output stream so far by this call
to
fprintf. No argument is converted, but one is consumed. If the
conversion
specification includes any flags, a field width, or a precision, the
behavior is
undefined.
Mais curieusement, je confirme que ça ne fonctionne pas avec MinGW
sous Vista SP2.
J'avais vérifié que ce spécificateur existait bien pour printf.
J'ai testé sous Visual C++ Express 2008, et au premier essai, il lève
une assertion.
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
mais on peut l'activer avec la commande
/* Enable or disable support of the %n format in printf, _printf_l,
wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
et ça fonctionne sans problèmes ensuite.
Mystère, avec GCC.
Bon, je venais de découvrir %n, mais il ne devrait pas me manquer plus
que ça...
J'avais vérifié que ce spécificateur existait bien pour printf.
J'ai testé sous Visual C++ Express 2008, et au premier essai, il lève
une assertion.
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
mais on peut l'activer avec la commande
/* Enable or disable support of the %n format in printf, _printf_l,
wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
et ça fonctionne sans problèmes ensuite.
Mystère, avec GCC.
Bon, je venais de découvrir %n, mais il ne devrait pas me manquer plus
que ça...
J'avais vérifié que ce spécificateur existait bien pour printf.
J'ai testé sous Visual C++ Express 2008, et au premier essai, il lève
une assertion.
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
mais on peut l'activer avec la commande
/* Enable or disable support of the %n format in printf, _printf_l,
wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
et ça fonctionne sans problèmes ensuite.
Mystère, avec GCC.
Bon, je venais de découvrir %n, mais il ne devrait pas me manquer plus
que ça...
GurneyH, le 26/02/2010 a écrit :
[...]
> J'avais vérifié que ce spécificateur existait bien pour printf.
> J'ai testé sous Visual C++ Express 2008, et au premier essai, il lè ve
> une assertion.
> Après recherche, ce spécificateur est désactivé avec le compila teur de
> Microsoft, pour des raisons de sécurité(bien compréhensible en fa it.),
> mais on peut l'activer avec la commande
> /* Enable or disable support of the %n format in printf, _printf_l,
> wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
> et ça fonctionne sans problèmes ensuite.
Même compilo, mêmes résultats dans Windows 7.
> Mystère, avec GCC.
Ça fonctionne, toujours dans Windows 7, avec le gcc 3.4.4 de cygwin. Ça
fonctionne également dans Ubuntu Karmic avec gcc 4.4.1.
> Bon, je venais de découvrir %n, mais il ne devrait pas me manquer plu s
> que ça...
Je ne connaissais pas.
--
Pierre Maurette
GurneyH, le 26/02/2010 a écrit :
[...]
> J'avais vérifié que ce spécificateur existait bien pour printf.
> J'ai testé sous Visual C++ Express 2008, et au premier essai, il lè ve
> une assertion.
> Après recherche, ce spécificateur est désactivé avec le compila teur de
> Microsoft, pour des raisons de sécurité(bien compréhensible en fa it.),
> mais on peut l'activer avec la commande
> /* Enable or disable support of the %n format in printf, _printf_l,
> wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
> et ça fonctionne sans problèmes ensuite.
Même compilo, mêmes résultats dans Windows 7.
> Mystère, avec GCC.
Ça fonctionne, toujours dans Windows 7, avec le gcc 3.4.4 de cygwin. Ça
fonctionne également dans Ubuntu Karmic avec gcc 4.4.1.
> Bon, je venais de découvrir %n, mais il ne devrait pas me manquer plu s
> que ça...
Je ne connaissais pas.
--
Pierre Maurette
GurneyH, le 26/02/2010 a écrit :
[...]
> J'avais vérifié que ce spécificateur existait bien pour printf.
> J'ai testé sous Visual C++ Express 2008, et au premier essai, il lè ve
> une assertion.
> Après recherche, ce spécificateur est désactivé avec le compila teur de
> Microsoft, pour des raisons de sécurité(bien compréhensible en fa it.),
> mais on peut l'activer avec la commande
> /* Enable or disable support of the %n format in printf, _printf_l,
> wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
> et ça fonctionne sans problèmes ensuite.
Même compilo, mêmes résultats dans Windows 7.
> Mystère, avec GCC.
Ça fonctionne, toujours dans Windows 7, avec le gcc 3.4.4 de cygwin. Ça
fonctionne également dans Ubuntu Karmic avec gcc 4.4.1.
> Bon, je venais de découvrir %n, mais il ne devrait pas me manquer plu s
> que ça...
Je ne connaissais pas.
--
Pierre Maurette
int a;
char const *s = "Hello world";
printf("%s%nn", s, &a);
Ne fonctionne pas chez moi (MinGW).Seulement une autre personne également sous MinGW compile ce code, et
il semble que le spécificateur %n est ignoré. : si on initialise la
variable a avec une valeur quelconque, on retrouve cette valeur après
l'appel de printf.
J'ai testé sous Visual C++ Express 2008, et au premier essai, il lève
une assertion.
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
mais on peut l'activer avec la commande
/* Enable or disable support of the %n format in printf, _printf_l,
wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
et ça fonctionne sans problèmes ensuite.
Mystère, avec GCC.
int a;
char const *s = "Hello world";
printf("%s%nn", s, &a);
Ne fonctionne pas chez moi (MinGW).
Seulement une autre personne également sous MinGW compile ce code, et
il semble que le spécificateur %n est ignoré. : si on initialise la
variable a avec une valeur quelconque, on retrouve cette valeur après
l'appel de printf.
J'ai testé sous Visual C++ Express 2008, et au premier essai, il lève
une assertion.
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
mais on peut l'activer avec la commande
/* Enable or disable support of the %n format in printf, _printf_l,
wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
et ça fonctionne sans problèmes ensuite.
Mystère, avec GCC.
int a;
char const *s = "Hello world";
printf("%s%nn", s, &a);
Ne fonctionne pas chez moi (MinGW).Seulement une autre personne également sous MinGW compile ce code, et
il semble que le spécificateur %n est ignoré. : si on initialise la
variable a avec une valeur quelconque, on retrouve cette valeur après
l'appel de printf.
J'ai testé sous Visual C++ Express 2008, et au premier essai, il lève
une assertion.
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
mais on peut l'activer avec la commande
/* Enable or disable support of the %n format in printf, _printf_l,
wprintf, _wprintf_l-family functions. _set_printf_count_output(1);
et ça fonctionne sans problèmes ensuite.
Mystère, avec GCC.
GurneyH écrivit :Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
Ah ! « Bien compréhensible » ? Bin moi j'ai toujours pas compris la
raison de sécurité qui fait interdire %n, mais qui laisse strcpy() et
tout plein d'autres fonctions...
GurneyH écrivit :
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
Ah ! « Bien compréhensible » ? Bin moi j'ai toujours pas compris la
raison de sécurité qui fait interdire %n, mais qui laisse strcpy() et
tout plein d'autres fonctions...
GurneyH écrivit :Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
Ah ! « Bien compréhensible » ? Bin moi j'ai toujours pas compris la
raison de sécurité qui fait interdire %n, mais qui laisse strcpy() et
tout plein d'autres fonctions...
Antoine Leca scripsit :GurneyH écrivit :Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
Ah ! « Bien compréhensible » ? Bin moi j'ai toujours pas compris la
raison de sécurité qui fait interdire %n, mais qui laisse strcpy() et
tout plein d'autres fonctions...
Bon, alors les problèmes de scrcpy() et consorts, je vois, par contre,
celui de %n c'est quoi en fait ?
Antoine Leca scripsit :
GurneyH écrivit :
Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
Ah ! « Bien compréhensible » ? Bin moi j'ai toujours pas compris la
raison de sécurité qui fait interdire %n, mais qui laisse strcpy() et
tout plein d'autres fonctions...
Bon, alors les problèmes de scrcpy() et consorts, je vois, par contre,
celui de %n c'est quoi en fait ?
Antoine Leca scripsit :GurneyH écrivit :Après recherche, ce spécificateur est désactivé avec le compilateur de
Microsoft, pour des raisons de sécurité(bien compréhensible en fait.),
Ah ! « Bien compréhensible » ? Bin moi j'ai toujours pas compris la
raison de sécurité qui fait interdire %n, mais qui laisse strcpy() et
tout plein d'autres fonctions...
Bon, alors les problèmes de scrcpy() et consorts, je vois, par contre,
celui de %n c'est quoi en fait ?
Manuel P gouri -Gonnard crivit :
> Antoine Leca scripsit :
>> GurneyH crivit :
>>> Apr s recherche, ce sp cificateur est d sactiv avec le compilateur de
>>> Microsoft, pour des raisons de s curit (bien compr hensible en fait.) ,
>> Ah ! Bien compr hensible ? Bin moi j'ai toujours pas compris la
>> raison de s curit qui fait interdire %n, mais qui laisse strcpy() et
>> tout plein d'autres fonctions...
> Bon, alors les probl mes de scrcpy() et consorts, je vois, par contre,
> celui de %n c'est quoi en fait ?
D'apr s ISO/C I TR 24731-1, le probl me ce serait des attaques contre
des printf qui ne contr leraient pas leur cha ne de format ; cas type :
printf(argv);
Au d part, c'est un truc pas sain (du m me acabit que n'importe quel
d bordement de tampon). Mais le cas-qui-tue, c'est si l'attaquant
profite de ce vecteur d'attaque et introduit des %n dans la cha ne de
format d'attaque : cela donne la possibilit d' crire pas mal de choses
(et surtout des valeurs 0) des adresses pass es en param tre printf.
En gros, cela devient du m me niveau que gets(), impossible contrer.
Tir de WG14 N1147 page 12 ; et s rement issu d'une attaque subie par MS
ou des analyses de circonstances aggravantes de certains d fauts.
Vu comme cela, cela para t idiot : il suffit de s'imposer de NE PAS
utiliser des printf(cha ne_utilisateur,...), une politique de s curit
raisonnable (c'est d'ailleurs la position implicite du comit C).
Le vrai souci, c'est la d fense en profondeur : comme chacun sait, les
cha nes de format font partie des choses les plus faciles rep rer dans
un binaire C : donc un attaquant peut chercher viser de telles
cha nes, changer le caract re qui suit un % par un n et le pi ge est
ouvert : par exemple, cela revient modifier un code qui fait
printf("%x", &toto);
en
printf("%n", &toto);
soit
toto = 0;
Une circonstance aggravante, en terme de s ret , c'est que la fonction
crire qui est sous-tendue par %n n'est pas naturellement associ e
printf() (cf. l'enfilade pour s'en rendre compte) : en cons quence de
nombreuses analyses de s ret risquent de passer c t du pi ge
potentiel (et l aussi, vu la virulence des propos, j'ai comme dans
l'id e que cela a d se passer en pratique au sud de Vancouver ;
cf. aussi les vuln rabilit s WMF r p tition, qui sont bas es sur le
m me d faut fonctionnel de s ret ).
mon sens, il s'agit quand m me de discussions plut t alambiqu es ; et
toute solution qui continue utiliser C mais cherche le faire de
mani re s re me para t mal embouch e par principe.
Mais bon, le code C que je vois personnellement n'a pas, et de TR S
loin, le niveau de s curit de ces discussions-ci, et je n'ai jamais vu
un code C qui soit suffisamment gros pour que l'option de r crire soit
r ellement in-envisageable ; donc mon avis n'a pas vraiment d'utilit .
Antoine
Manuel P gouri -Gonnard crivit :
> Antoine Leca scripsit :
>> GurneyH crivit :
>>> Apr s recherche, ce sp cificateur est d sactiv avec le compilateur de
>>> Microsoft, pour des raisons de s curit (bien compr hensible en fait.) ,
>> Ah ! Bien compr hensible ? Bin moi j'ai toujours pas compris la
>> raison de s curit qui fait interdire %n, mais qui laisse strcpy() et
>> tout plein d'autres fonctions...
> Bon, alors les probl mes de scrcpy() et consorts, je vois, par contre,
> celui de %n c'est quoi en fait ?
D'apr s ISO/C I TR 24731-1, le probl me ce serait des attaques contre
des printf qui ne contr leraient pas leur cha ne de format ; cas type :
printf(argv);
Au d part, c'est un truc pas sain (du m me acabit que n'importe quel
d bordement de tampon). Mais le cas-qui-tue, c'est si l'attaquant
profite de ce vecteur d'attaque et introduit des %n dans la cha ne de
format d'attaque : cela donne la possibilit d' crire pas mal de choses
(et surtout des valeurs 0) des adresses pass es en param tre printf.
En gros, cela devient du m me niveau que gets(), impossible contrer.
Tir de WG14 N1147 page 12 ; et s rement issu d'une attaque subie par MS
ou des analyses de circonstances aggravantes de certains d fauts.
Vu comme cela, cela para t idiot : il suffit de s'imposer de NE PAS
utiliser des printf(cha ne_utilisateur,...), une politique de s curit
raisonnable (c'est d'ailleurs la position implicite du comit C).
Le vrai souci, c'est la d fense en profondeur : comme chacun sait, les
cha nes de format font partie des choses les plus faciles rep rer dans
un binaire C : donc un attaquant peut chercher viser de telles
cha nes, changer le caract re qui suit un % par un n et le pi ge est
ouvert : par exemple, cela revient modifier un code qui fait
printf("%x", &toto);
en
printf("%n", &toto);
soit
toto = 0;
Une circonstance aggravante, en terme de s ret , c'est que la fonction
crire qui est sous-tendue par %n n'est pas naturellement associ e
printf() (cf. l'enfilade pour s'en rendre compte) : en cons quence de
nombreuses analyses de s ret risquent de passer c t du pi ge
potentiel (et l aussi, vu la virulence des propos, j'ai comme dans
l'id e que cela a d se passer en pratique au sud de Vancouver ;
cf. aussi les vuln rabilit s WMF r p tition, qui sont bas es sur le
m me d faut fonctionnel de s ret ).
mon sens, il s'agit quand m me de discussions plut t alambiqu es ; et
toute solution qui continue utiliser C mais cherche le faire de
mani re s re me para t mal embouch e par principe.
Mais bon, le code C que je vois personnellement n'a pas, et de TR S
loin, le niveau de s curit de ces discussions-ci, et je n'ai jamais vu
un code C qui soit suffisamment gros pour que l'option de r crire soit
r ellement in-envisageable ; donc mon avis n'a pas vraiment d'utilit .
Antoine
Manuel P gouri -Gonnard crivit :
> Antoine Leca scripsit :
>> GurneyH crivit :
>>> Apr s recherche, ce sp cificateur est d sactiv avec le compilateur de
>>> Microsoft, pour des raisons de s curit (bien compr hensible en fait.) ,
>> Ah ! Bien compr hensible ? Bin moi j'ai toujours pas compris la
>> raison de s curit qui fait interdire %n, mais qui laisse strcpy() et
>> tout plein d'autres fonctions...
> Bon, alors les probl mes de scrcpy() et consorts, je vois, par contre,
> celui de %n c'est quoi en fait ?
D'apr s ISO/C I TR 24731-1, le probl me ce serait des attaques contre
des printf qui ne contr leraient pas leur cha ne de format ; cas type :
printf(argv);
Au d part, c'est un truc pas sain (du m me acabit que n'importe quel
d bordement de tampon). Mais le cas-qui-tue, c'est si l'attaquant
profite de ce vecteur d'attaque et introduit des %n dans la cha ne de
format d'attaque : cela donne la possibilit d' crire pas mal de choses
(et surtout des valeurs 0) des adresses pass es en param tre printf.
En gros, cela devient du m me niveau que gets(), impossible contrer.
Tir de WG14 N1147 page 12 ; et s rement issu d'une attaque subie par MS
ou des analyses de circonstances aggravantes de certains d fauts.
Vu comme cela, cela para t idiot : il suffit de s'imposer de NE PAS
utiliser des printf(cha ne_utilisateur,...), une politique de s curit
raisonnable (c'est d'ailleurs la position implicite du comit C).
Le vrai souci, c'est la d fense en profondeur : comme chacun sait, les
cha nes de format font partie des choses les plus faciles rep rer dans
un binaire C : donc un attaquant peut chercher viser de telles
cha nes, changer le caract re qui suit un % par un n et le pi ge est
ouvert : par exemple, cela revient modifier un code qui fait
printf("%x", &toto);
en
printf("%n", &toto);
soit
toto = 0;
Une circonstance aggravante, en terme de s ret , c'est que la fonction
crire qui est sous-tendue par %n n'est pas naturellement associ e
printf() (cf. l'enfilade pour s'en rendre compte) : en cons quence de
nombreuses analyses de s ret risquent de passer c t du pi ge
potentiel (et l aussi, vu la virulence des propos, j'ai comme dans
l'id e que cela a d se passer en pratique au sud de Vancouver ;
cf. aussi les vuln rabilit s WMF r p tition, qui sont bas es sur le
m me d faut fonctionnel de s ret ).
mon sens, il s'agit quand m me de discussions plut t alambiqu es ; et
toute solution qui continue utiliser C mais cherche le faire de
mani re s re me para t mal embouch e par principe.
Mais bon, le code C que je vois personnellement n'a pas, et de TR S
loin, le niveau de s curit de ces discussions-ci, et je n'ai jamais vu
un code C qui soit suffisamment gros pour que l'option de r crire soit
r ellement in-envisageable ; donc mon avis n'a pas vraiment d'utilit .
Antoine