Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Erradicating a Buffer Overflow

Reply
Thread Tools

Erradicating a Buffer Overflow

 
 
Walter Roberson
Guest
Posts: n/a
 
      10-25-2005
In article <(E-Mail Removed)1.va.comcast.net >,
Arctic Fidelity <(E-Mail Removed)> wrote:
>I personally came accross a sample
>usage of sscanf in documentation, and found that it was much faster
>compared to my original idea of single character stepping through the date
>string.


Faster? In what sense? Faster to write the code, or faster execution
time, or faster to debug the security problems?
--
Chocolate is "more than a food but less than a drug" -- RJ Huxtable
 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      10-25-2005
SM Ryan <(E-Mail Removed)> wrote:

> "Arctic Fidelity" <(E-Mail Removed)> wrote:
>
> # sscanf(argv[1],
>
> # after the time section of the string, and overflow the program. My
> # question is, what is the proper way of handling this? How can I remedy it?
>
> Do you realize you aren't required to use *scanf? If the tools are
> too difficult to use, get better tools.


And what better tool would you use in this particular situation?

Richard
 
Reply With Quote
 
 
 
 
Arctic Fidelity
Guest
Posts: n/a
 
      10-25-2005
On Mon, 24 Oct 2005 20:52:37 -0400, Walter Roberson
<(E-Mail Removed)-cnrc.gc.ca> wrote:

> Faster? In what sense? Faster to write the code, or faster execution
> time, or faster to debug the security problems?


Faster to debug the code, the security issues, faster to write the code,
though I am not sure about execution speed, I haven't tested that.

- Arctic Fidelity

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
 
Reply With Quote
 
SM Ryan
Guest
Posts: n/a
 
      10-25-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard Bos) wrote:
# SM Ryan <(E-Mail Removed)> wrote:
#
# > "Arctic Fidelity" <(E-Mail Removed)> wrote:
# >
# > # sscanf(argv[1],
# >
# > # after the time section of the string, and overflow the program. My
# > # question is, what is the proper way of handling this? How can I remedy it?
# >
# > Do you realize you aren't required to use *scanf? If the tools are
# > too difficult to use, get better tools.
#
# And what better tool would you use in this particular situation?

I usually write my own parser with things like state machines, strchr,
isxxx, strtol, etc. I prefer writing longer code if necessary to ensure
I have it under control.

Then again I'm not the one who felt the need to ask others if a scanf
format was safe.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Why are we here?
whrp
 
Reply With Quote
 
WhoCares?
Guest
Posts: n/a
 
      10-25-2005
> BTW, I note that you're doing this to a command line argument. You are
> aware that any single command line argument - that is, any single member
> of argv[] - is highly unlikely to contain your _entire_ command line,
> and will probably not even contain any spaces unless what- or whoever
> called your program has taken special precautions to see that it does?


Would you please tell me how to do that?
In my _limited_ knowledge, if the command line contains whitespaces
then the strings separated by these whitespaces are passed as different
members of argv[]. How to get all that in a single member?

Thanks in advance.

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      10-25-2005
In article <(E-Mail Removed). com>,
WhoCares? <(E-Mail Removed)> wrote:
>> BTW, I note that you're doing this to a command line argument. You are
>> aware that any single command line argument - that is, any single member
>> of argv[] - is highly unlikely to contain your _entire_ command line,
>> and will probably not even contain any spaces unless what- or whoever
>> called your program has taken special precautions to see that it does?


>Would you please tell me how to do that?
>In my _limited_ knowledge, if the command line contains whitespaces
>then the strings separated by these whitespaces are passed as different
>members of argv[]. How to get all that in a single member?


Mechanism to pass spaces in as arguments are OS or shell specific,
and should be asked in an appropriate newsgroup.

[OT]

Commonly, passing spaces in involves quoting of arguments. But the
exact quote characters and escape rules are OS or shell specific.

Unix ksh:

A3="arg 3"
./myprog "arg 1" 'arg 2' $A3

The behaviour in the last of those cases especially is not the same
on other shells or OS's.
--
I am spammed, therefore I am.
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      10-25-2005
"WhoCares?" <(E-Mail Removed)> wrote:

[ Please do not remove attributions that are still relevant. Thanks. ]

> > BTW, I note that you're doing this to a command line argument. You are
> > aware that any single command line argument - that is, any single member
> > of argv[] - is highly unlikely to contain your _entire_ command line,
> > and will probably not even contain any spaces unless what- or whoever
> > called your program has taken special precautions to see that it does?

>
> Would you please tell me how to do that?


Depends on the OS, and under some OSes, on the shell.

> In my _limited_ knowledge, if the command line contains whitespaces
> then the strings separated by these whitespaces are passed as different
> members of argv[].


That's the most usual case, yes. But consider an OS which does not have
a command line, but allows you to fill in program parameters in the
symlink properties dialog. Or consider a shell which allows you to
escape whitespace.

Richard
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      10-25-2005
In article <(E-Mail Removed)1.va.comcast.net >,
Arctic Fidelity <(E-Mail Removed)> wrote:
>On Mon, 24 Oct 2005 20:52:37 -0400, Walter Roberson
><(E-Mail Removed)-cnrc.gc.ca> wrote:


>> Faster? In what sense? Faster to write the code, or faster execution
>> time, or faster to debug the security problems?


>Faster to debug the code, the security issues, faster to write the code,
>though I am not sure about execution speed, I haven't tested that.


You snipped the context that you had encountered scanf() in some
documentation and had found using it to be faster.

With regard to the debugging the security issues, you should be
taking into account that in order to debug those issues, you ended
up having to post to Usenet and to track through several days of
discussions in order to get the security issues clear. If you had
written your own small code section that did not use scanf(),
then you could have had it done in perhaps half an hour. And since
debugging the code includes debugging the security issues, you
weren't done debugging the code for at least several days.

Similarily, part of writing the code is debugging it, and documenting
it. Again you had the several days of delay while you found out
what scanf() does. So writing the code was in fact slower than if you
had taken a more direct approach without scanf().

The only "faster" left is execution time, which you indicate that
you did not measure.

I think you should be reconsidering whether it was any "faster"
to use scanf() or not. It looks to me that using scanf() was slower
in every measure you were taking into account.
--
Chocolate is "more than a food but less than a drug" -- RJ Huxtable
 
Reply With Quote
 
Arctic Fidelity
Guest
Posts: n/a
 
      10-25-2005
On Tue, 25 Oct 2005 11:40:23 -0400, Walter Roberson
<(E-Mail Removed)-cnrc.gc.ca> wrote:

>>> Faster? In what sense? Faster to write the code, or faster execution
>>> time, or faster to debug the security problems?

>
>> Faster to debug the code, the security issues, faster to write the code,
>> though I am not sure about execution speed, I haven't tested that.

>
> You snipped the context that you had encountered scanf() in some
> documentation and had found using it to be faster.


My sincere apologies. I shall try to take better note of that.

> With regard to the debugging the security issues, you should be
> taking into account that in order to debug those issues, you ended
> up having to post to Usenet and to track through several days of
> discussions in order to get the security issues clear. If you had
> written your own small code section that did not use scanf(),
> then you could have had it done in perhaps half an hour. And since
> debugging the code includes debugging the security issues, you
> weren't done debugging the code for at least several days.


Actually, I received a response that well enough answered my question to
the point where I knew where to look and how to look in my documentation
that I was able to have the entire question settled from post to end in
far less than half a day. The time that it would have taken for me to
properly fix and make an even equivalently working program of my own,
would have been at least that long, since my speed at writing C code is
not nearly fast enough for that yet.

> Similarily, part of writing the code is debugging it, and documenting
> it. Again you had the several days of delay while you found out
> what scanf() does. So writing the code was in fact slower than if you
> had taken a more direct approach without scanf().


Whether the approach is more direct or not is debatable. I would say that
in comparison with the estimated amount of time it would have taken to
properly fix and verify the code I would have written, sscanf() + Usenet
discussion time (and by this I mean the time before I fixed the problem)
was faster.

> The only "faster" left is execution time, which you indicate that
> you did not measure.
>
> I think you should be reconsidering whether it was any "faster"
> to use scanf() or not. It looks to me that using scanf() was slower
> in every measure you were taking into account.


Having reconsidered it, and I have come to the conclusion that sscanf
seems to be at least equivalent in "speed" (with regards to those issues
stated above) to writing my own code by hand, taking into account my
relative speed at writing such code at this moment in time.

- Arctic Fidelity

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
 
Reply With Quote
 
Arctic Fidelity
Guest
Posts: n/a
 
      10-25-2005
On Tue, 25 Oct 2005 08:43:33 -0400, SM Ryan
<(E-Mail Removed)> wrote:

> Then again I'm not the one who felt the need to ask others if a scanf
> format was safe.


In some regards, I feel almost as though having asked this question has
earned me even the slightest bit of disdain from some particular readers
of this group. Am I missing something? Forgive me if I am reading into
such things. I am under the impression, perhaps, that scanf and such
functions have at them a group of people who are in at least partially
strong objection to their use? If so, is their some history or methods or
something else about these scanf tools with which I am not familar that
has earned them such apparent dislike? If not, well, then do please ignore
the far too naive jabberings of a simpleton of the C world, a relative
newcomer.

- Arctic Fidelity

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Using aspnet Impersonation, ASPNET_SETREG, applicaton throws buffer overflow. jay@gloryfish.org ASP .Net 2 10-21-2005 04:39 PM
??? Possible Buffer Overflow ??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 2 08-31-2005 04:39 PM
ASP.NET Crashing on IIS 5.0 - Buffer overflow =?Utf-8?B?Lk5FVCBEZXY=?= ASP .Net 1 08-11-2005 08:04 PM
Upload IOS to 803 fails (buffer overflow) stapla222 Cisco 1 04-11-2005 10:33 PM
buffer overflow Wojtek Cisco 1 04-03-2005 04:03 PM



Advertisments