What is the potential problem?
happy
#include <stdlib.h>
#include <stdio.h>
void Error(char* s)
{
printf(s);
return;
}
int main()
{
int *p;
p = (int*)malloc(sizeof(int));
if(!p)
{
Error("memory error");
Error("Quitting....\n");
exit(1);
}
else
{
/*some stuff to use p*/
}
free(p);
return 0;
}
Find potential problem with the error function.. a security concern..
Please tell me what can be the potential problem. Is this the printf
(p) because p can contain conversion specifiers?
bartc
"Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
news:error-2010...@ram.dialup.fu-berlin.de...
> happy <hppym...@yahoo.com> writes:
>>Please tell me what can be the potential problem. Is this the printf
>>(p) because p can contain conversion specifiers?
>
> because then it would not be possible to call it from other linking
> units, and in /this/ compilation unit, it is only called in:
>
>>Error("memory error");
>>Error("Quitting....\n");
>
An external routine may not know that "%" characters are special in the
message strings passed to Error().
But that they would just make it go wrong, I can't see a security issue. And
if the caller of Error() was malicious, he could just call his own printf()
function with whatever he likes.
--
Bartc
Eric Sosman
That would be my guess at what the question's author was
trying to get at. The question is poorly framed, though,
since we don't have enough context. There is no "security
concern," for example, if all the Error strings are provided
by a trusted source, someone who knows not to put percent
signs in them.
There are other potential problems, depending on what you
consider a "problem." For example, the output might not appear
at all if the caller of Error forgets to end with a '\n' (in
the example, the output would be "memory errorQuitting....\n"
because Error does not supply its own line break). Also, Error
sends its messages to stdout, whereas they probably ought to go
to stderr.
There's also a useless `return' statement, and the caller
has a useless cast and a non-portable exit status. All in all,
I'd say the question is poorly composed.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Kalle Olavi Niemitalo
> But that they would just make it go wrong, I can't see a security
> issue. And if the caller of Error() was malicious, he could just call
> his own printf() function with whatever he likes.
The security issue is if the caller is not malicious but is
passing a string from a malicious source, e.g. if an authorized
user is running the program to view some file on a floppy disk
that he found lying on the street next to the office.
Most conversion specifications in this printf call would just
cause printf to read a va_arg that was not provided by the
caller, and then either display it (which as such may already
write some secret to a place that unauthorized people can see) or
dereference it as a pointer and possibly crash (for "%s"), but
"%n" is unusual in that it actually writes to memory. The
attacker can control the value written (i.e. the number of
characters output so far), and by suitably corrupting the stack
or other data structures, he may be able to lure the program
into executing some code of his choosing.
Paul N
In addition to what the others have said - the function "Error"
doesn't actually stop the program, which one might expect it to do.
io_x
"happy" <hppym...@yahoo.com> ha scritto nel messaggio
news:292b7859-81c4-42b7...@a21g2000yqc.googlegroups.com...
>I read an unanswered interview question somewhere :
>
> #include <stdlib.h>
> #include <stdio.h>
> void Error(char* s)
> {
> printf(s);
fflush(stdout);
> return;
> }
>
Francis Glassborow
Perhaps I am being stupid (it would not be the first time :-) ) but why
does this code not use puts()? There is then no problem with the string
being passed as an argument. Of course that would not be a good
interview question but it would be a good answer. In addition fputs()
could be used to send the error message to another, more appropriate,
output stream.
The only justification for defining an Error() function is if you wish
to do more than simply output the error message.
Richard Heathfield
> io_x wrote:
>> "happy" <hppym...@yahoo.com> ha scritto nel messaggio
>> news:292b7859-81c4-42b7...@a21g2000yqc.googlegroups.com...
>>> I read an unanswered interview question somewhere :
>>>
>>> #include <stdlib.h>
>>> #include <stdio.h>
>>> void Error(char* s)
>>> {
>>> printf(s);
>> printf("%s", s);
>> fflush(stdout);
>>> return;
>>> }
>>>
>>
>
> Perhaps I am being stupid (it would not be the first time :-) ) but why
> does this code not use puts()?
Because it doesn't do the same thing. But you could use fputs if you
like: fputs(s, stdout); fflush(stdout);
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
io_x
"Francis Glassborow" <francis.g...@btinternet.com> ha scritto nel
messaggio news:ZKOdnU1yBeztZd_W...@bt.com...
> io_x wrote:
>> "happy" <hppym...@yahoo.com> ha scritto nel messaggio
>> news:292b7859-81c4-42b7...@a21g2000yqc.googlegroups.com...
>>> I read an unanswered interview question somewhere :
>>>
>>> #include <stdlib.h>
>>> #include <stdio.h>
>>> void Error(char* s)
>>> {
>>> printf(s);
>> printf("%s", s);
>> fflush(stdout);
>>> return;
>>> }
>>>
>>
>
> Perhaps I am being stupid (it would not be the first time :-) ) but why does
> this code not use puts()?
with the above function you can call
char *p=" and this\n";
Error("This is a error for this, "); Error(p);
that would print out
"This is a error for this, and this\n"
with puts() you have always one
"\n" printend at the end of the string so the result would be
"This is a error for this,\n"
" and this\n"