Qry : Behaviour of fgets -- ?

[Sheth Raxit]

Machine 1 :
bash-3.00$ uname -a
SunOS <hostname5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Fire-280R

bash-3.00$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/
specs
gcc version 2.95.3 20010315 (release)
Machine 2:
bash-2.05b$ uname -a
Linux <hostname2.4. 21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686
i386 GNU/Linux

bash-2.05b$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-
redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20)

bash-2.05b$ cat fgets_fail_test .c
#include<stdio. h>
#include <string.h>
#include<stdlib .h>

/* Demo fgets failed by Raxit Sheth & Gaurav Gupta */

int main()
{
char spcontent[100],sendrepfile[100];
FILE *spfp=NULL;
memset(sendrepf ile,0,100);
strcpy(sendrepf ile,"/tmp/filenotexists") ;
if ((spfp = fopen(sendrepfi le, "r")) == (FILE *)NULL)
{
printf("error in opening file %s",sendrepfile );fflush(stdout );
}
memset(spconten t, 0, sizeof(spconten t));

while (fgets(spconten t,40, spfp)!=NULL)
{
printf("The value of spcontent is
[%s]",spcontent);ff lush(stdout);;
}
return 0;
}
<simillar core dump occurs on both the system>
bash-2.05b$ gcc -Wall fgets_fail_test .c -o test
bash-2.05b$ ./test
error in opening file /tmp/filenotexistsSe gmentation fault (core
dumped)
bash-2.05b$ gdb ./test ./core.27887
GNU gdb Red Hat Linux (5.3.90-0.20030710.40rh )
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging
symbols found)...Using host libthread_db library "/lib/tls/
libthread_db.so .1".

Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(n o debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
(gdb) where
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
#1 0x0804854b in main ()
(gdb) frame 0
#0 0xb7506444 in fgets () from /lib/tls/libc.so.6
(gdb) print errno
Cannot access memory at address 0xb74a7008
char *fgets(char *s, int n, FILE *stream)
Qry : What is the Behaviour if stream is NULL. ?

As per our understanding fgets should return NULL < and internally
gets should put check on stream, if it is not NULL then only should do
additional access of stream.

please ignore if it is known and would be great if you can point out
in the implementation detail.
--Gaurav Gupta & Raxit Sheth
http://www.barcamp.org/BarCampMumbaiOct2007 <----BarCampMumbaiOc t2007

[CBFalconer]

Bart van Ingen Schenau wrote:

>

.... snip ...

>
The standard does indeed not require that UB causes my next door
neighbour to turn into a piano, but that appears to be exactly the
behaviour of my DeathStation 9000.
Are you claiming that this behaviour is not correct?

That depends. Is he in tune? :-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Scott Lurndal]

Keith Thompson <ks***@mib.orgw rites:

[snip]

>As a programmer, of course, I can't depend on any such checks, since
not all implementations perform them, and that's going to remain the
case for a long time. It's still entirely *my* responsibility to
avoid passing invalid arguments to fgets. If the implementation helps
me out by catching certain errors, that's great (unless it imposes too
much of a burden on *correct* calls), but I can't count on it. If I
don't trust myself to get this right, I can always write a wrapper
that checks the arguments before calling fgets.

Indeed. One may as well expect strcpy to return EFAULT when provided
arguments in which the destination pointer refers to an
unmapped portion of the virtual address space (or a portion mapped
read-only, or a portion to which the process has no access).

This was actually proposed to the X/Open group at one point and was
quickly rejected due to performance and correctness constraints.

scott

[Barry Margolin]

In article <11************ **********@22g2 000hsm.googlegr oups.com>,
Sheth Raxit <ra************ @gmail.comwrote :

don't you think instead of "not saying" or "saying undefined
behaviour" any additional checks are put itself in std ?

This would be redundant and inefficient. Instead of the programmer
checking the return value of fopen() once, all the I/O functions would
have to check the value of the stream every time.

Consider an inner loop calling fgetc(). This is a very simple
operation, probably only about 5-10 instructions most of the time
(because of buffering -- if there's data in the buffer it just has to
copy one byte and increment the buffer pointer). Adding the NULL check
would slow it down by 20-30%, I suspect.

--
Barry Margolin, ba****@alum.mit .edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[Joe Wright]

CBFalconer wrote:

jacob navia wrote:

>Casper H.S. Dik wrote:

... snip ...

>>Dumping core is a good thing; you have a bug, it was caught.
Now go and fix your code.

Casper

Why error analysis is necessary?

Error analysis means trying to have a defined an in all cases
identical reaction to program errors.

This means that for each function we write, we try to
return a specified error report value if things go wrong.

In the case of fgets this implies:
o Testing for NULL.
o Testing for a bad value of n (<= 0)
o Testing for a NULL value in the receiving buffer.

NULLs are allowed in the receiving buffer, and don't matter since
they will either be beyond the line end or overwritten. It helps
to get the objective right before trying to code for it.

One is also allowed to snip obvious signatures, even though the
originator neglected to include a proper sig. marker. There are no
prizes for extreme laziness or rudeness.

Canonically,

char buff[80];
size_t size = sizeof buff;
while (fgets(buff, size, stream)) {
....
}
fgets will return NULL at EOF or error. The EOF condition is the normal
exit from the while loop.

fgets returns the value buff if it read something. We use strchr to
check for '\n' in buff indicating a complete line.

If the line is incomplete, either the line is longer than buff or it is
the last line of the stream and doesn't terminate with '\n'. To find out
which we use strchr searching for '\0' which will always succeed. If the
NUL is at buff[size-1] we assume the line is longer than buff. If the
NUL occurs earlier we assume an unterminated last line.

For well formed input we have enough information to do 'the right thing'
with the data.

Perversity.
It is apparently legal, if unusual, to have '\0' characters in text
files. fgets makes no exception for these NUL characters. If a too-long
line has a NUL in it, my logic above gets it wrong by assuming an
unterminated last line. Even if the line is terminated with '\n', if it
also contains NUL then using strcpy to move it from buff will fail
miserably.

All because NUL is legal in text streams. Or is it?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

Joe Wright wrote:

CBFalconer wrote:

>jacob navia wrote:

>>Casper H.S. Dik wrote:

... snip ...

>>>Dumping core is a good thing; you have a bug, it was caught.
Now go and fix your code.

Casper
Why error analysis is necessary?

Error analysis means trying to have a defined an in all cases
identical reaction to program errors.

This means that for each function we write, we try to
return a specified error report value if things go wrong.

In the case of fgets this implies:
o Testing for NULL.
o Testing for a bad value of n (<= 0)
o Testing for a NULL value in the receiving buffer.

NULLs are allowed in the receiving buffer, and don't matter since
they will either be beyond the line end or overwritten. It helps
to get the objective right before trying to code for it.

One is also allowed to snip obvious signatures, even though the
originator neglected to include a proper sig. marker. There are no
prizes for extreme laziness or rudeness.

Canonically,

char buff[80];
size_t size = sizeof buff;
while (fgets(buff, size, stream)) {
....
}
fgets will return NULL at EOF or error. The EOF condition is the
normal exit from the while loop.

fgets returns the value buff if it read something. We use strchr
to check for '\n' in buff indicating a complete line.

If the line is incomplete, either the line is longer than buff or
it is the last line of the stream and doesn't terminate with '\n'.
To find out which we use strchr searching for '\0' which will
always succeed. If the NUL is at buff[size-1] we assume the line
is longer than buff. If the NUL occurs earlier we assume an
unterminated last line.

For well formed input we have enough information to do 'the right
thing' with the data.

Perversity.
It is apparently legal, if unusual, to have '\0' characters in
text files. fgets makes no exception for these NUL characters. If
a too-long line has a NUL in it, my logic above gets it wrong by
assuming an unterminated last line. Even if the line is terminated
with '\n', if it also contains NUL then using strcpy to move it
from buff will fail miserably.

The constant response to all line lengths thing is easily handled
by ggets. If the NULLs in the line are affecting you, you could
easily modify ggets.zip to ignore them (which may not be the right
cure). See:

<http://cbfalconer.home .att.net/download/>

Barring i/o or malloc failures ggets always returns complete lines,
with the final '\n' removed. The penalty is exercising the malloc
subsystem.

It has been pointed out that ggets is vulnerable to deliberate
interference, since it continues to expand the buffer as long as
input is arriving (without a '\n'). I think this is negligible,
partly because it is hard to provide a continuous input. It
actually doesn't tie up indefinitely, since once the malloc system
refuses to expand it exits with error.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Army1987]

On Sat, 08 Sep 2007 10:03:32 -0400, Joe Wright wrote:

[...]To find out
which we use strchr searching for '\0' which will always succeed. If the
NUL is at buff[size-1] we assume the line is longer than buff.

Doesn't strlen(buf) != size - 1 do the same without looking that
weird?
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[Keith Thompson]

Joe Wright <jo********@com cast.netwrites:
[...]

Canonically,

char buff[80];
size_t size = sizeof buff;
while (fgets(buff, size, stream)) {
....
}

[...]

If the line is incomplete, either the line is longer than buff or it
is the last line of the stream and doesn't terminate with '\n'. To
find out which we use strchr searching for '\0' which will always
succeed. If the NUL is at buff[size-1] we assume the line is longer
than buff. If the NUL occurs earlier we assume an unterminated last
line.

[...]

strchr? Just use strlen.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:
[...]

It has been pointed out that ggets is vulnerable to deliberate
interference, since it continues to expand the buffer as long as
input is arriving (without a '\n'). I think this is negligible,
partly because it is hard to provide a continuous input.
actually doesn't tie up indefinitely, since once the malloc system
refuses to expand it exits with error.

No, it's not hard to provide a continuous input. In fact, it's
trivial, as I've demonstrated:

./my_program < /dev/zero

It
actually doesn't tie up indefinitely, since once the malloc system
refuses to expand it exits with error.

Which is not necessarily benign.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yah oo.comwrites:
[...]

>It has been pointed out that ggets is vulnerable to deliberate
interference , since it continues to expand the buffer as long as
input is arriving (without a '\n'). I think this is negligible,
partly because it is hard to provide a continuous input.
actually doesn't tie up indefinitely, since once the malloc system
refuses to expand it exits with error.

No, it's not hard to provide a continuous input. In fact, it's
trivial, as I've demonstrated:

./my_program < /dev/zero

>actually doesn't tie up indefinitely, since once the malloc system
refuses to expand it exits with error.

Which is not necessarily benign.

However, this assumes the evildoer has access to the machine, and
can access devices, and can redirect input to access such a device,
etc. etc. I don't think this generally applies.

Actually the suggestion I made earlier in this thread, of making
ggets ignore a zero byte, would foul this attack entirely. Since
ggets is intended to input text this is probably a harmless change
and doesn't affect the .h linkage file in the least.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Richard Tobin]

In article <46************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.netwrote :

>No, it's not hard to provide a continuous input. In fact, it's
trivial, as I've demonstrated:

./my_program < /dev/zero

>However, this assumes the evildoer has access to the machine, and
can access devices, and can redirect input to access such a device,
etc. etc. I don't think this generally applies.

What kind of input would someone have that *wouldn't* allow them that
kind of access? In the old days they might be sitting at a dumb
terminal, but now almost all remote access is from another computer
that can generate arbitrary data.

On the other hand, most remote access these days is probably through
HTTP, and for that the size of the data is usually known before the
remote application gets hold of it. It can be very big of course.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.