finken@iraul1.ira.uka.de (Michael Finken) (11/16/88)
Hello World,
We are running a Vax 11/750 with 4.3bsd and provide anonymous ftp services.
Two days ago a friendly user showed us how the bug in ftpd works. As we are
lucky to have the sources for ftpd, I tried to find out what is wrong...
- The bug is the result of a typical *feature* of unix library routines.
A lot of them do something, leave the result in a static area
and return a pointer to it, so does getpwnam(). A second call to
getpwnam() overwrites the output of the first.
What's the slogan for such stuff? "It's a feature, not a bug"
My fix works in the yacc parsing entry (or whatever the correct word maybe in
English) for pathnames. ftp allows the user to specify ~username as short
for the user's home directory. An internal routine uses getpwnam() to retrieve
the requested home directory. All ftpd commands referring to pathnames require
a symbol 'check_login', which sends an appropriate reply code if the user is
not yet logged in. But yacc also executes the action routine for pathname
parsing...
The only change I made was in the file ftpcmd.y (/src/etc/ftpd/ftpcmd.y) of
the 4.3bsd sources. I hope the diff command was correct, the lines starting
with '>' are the new ones...
----------------------------------------------------------------here we go--
427c427,428
< if ($1 && strncmp((char *) $1, "~", 1) == 0) {
---
> if (logged_in) {
> if ($1 && strncmp((char *) $1, "~", 1) == 0) {
434c435
< } else
---
> } else
435a437,438
> } else
> $$ = NULL;
------------------------------------------------------------------end-------
We installed this patch and it worked, but I am only a 'medium level' beginner
with unix, so if you think about applying this fix, check first what it does.
My boss tested the new version; but we're all only humans...
Bye,
Michael Finken, Postmaster@unika1.ira.uka.depdb@sei.cmu.edu (Patrick Barron) (11/17/88)
The "official" fix was posted in comp.bugs.4bsd.ucb-fixes a couple of weeks ago. --Pat.
mohamed@popvax.harvard.edu (Mohamed Ellozy) (11/17/88)
In article <2978@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: > >The "official" fix was posted in comp.bugs.4bsd.ucb-fixes a couple of weeks >ago. > Has any expletive deleted vendor done anything official about it? Or is it just tough luck for sites that run UNIX and do not follow the net? On the same topic, has any vendor sent fixes to the bugs that the worm exploited to ALL users via paper mail? The real lesson from the worm and ftpd is that vendors are not doing a very good job. I have found tftpd enabled on two probably plain vanilla out of the box Sun 386i's. And so on and so forth.
vjs@rhyolite.SGI.COM (Vernon Schryver) (11/19/88)
In article <271@popvax.harvard.edu>, mohamed@popvax.harvard.edu (Mohamed Ellozy) writes: > On the same topic, has any vendor sent fixes to the bugs that the worm > exploited to ALL users via paper mail? Do you think that vendors expect to be notified "via paper mail" by the ultimate vendor, BSD? Do you think that vendors think that $400 obligates BSD to fix all bugs forever? Do you think that vendors expect much out of AT&T for our many, many dollars? Do all "users" send support $ to their vendors? Do you? Do you think that postage, not to mention paper or time to write are free? Have you checked how much it costs to keep a good support person happily answering the phone lately? > The real lesson from the worm and ftpd is that vendors are not doing a very > good job. I have found tftpd enabled on two probably plain vanilla out > of the box Sun 386i's. And so on and so forth. What would be required to fit your definition of "good job?" Do you expect Sun to find every boxed 386i in the universe, and fix it within two weeks of the discovery of the problem? What about Sun 4's or Sun 3's? Sun 2's? Sun 1's? Forever? Are the sendmail and ftpd bugs the worst bugs in any current product from Sun or any other vendor? If so, you think most users of that product agree with you? Even the majority who are not directly connected to the Internet? Do you think every employee of every vendor has nothing better to do than read the megabytes of text posted about the recent problems? Do you think it is not almost pure drivel? (with some sterling exceptions, of course). Do you think that all or even most vendors are connected to usenet? To the Internet? What do you want Sun to do? Mail a $20 cartridge tape with new binaries for ftpd and sendmail to every household and dormatory room in the world within days of finding the problem? Do you want new software tested first? Do you know that there is at least one new bug in the fixed ftpd from BSD? Do you think that not having good wtmp records of the use of ftp is a security problem? How long will it be until you will be able to get fixed binaries from the sun-spots archives for your suns? At least some vendors, including, as far as I can tell, Sun, are doing a far better job of trying to fix such problems than vendors of other, more dangerous appliances. How many lives in how many years were consumed by Corvairs or Pintos after it was well known that problems existed? Be fair, or at least accurate. If you have constructive suggestions on how a vendor could release free fixes for things like the sendmail or ftpd bugs without getting in trouble with the Internet Police, with customers who pay for support, with whose who don't have the target machine and don't want to pay for the bandwidth, and with those who pay the bills, please let me know. SGI has found nothing that works. Vernon Schryver Silicon Graphics vjs@sgi.com
pdb@sei.cmu.edu (Patrick Barron) (11/19/88)
In article <271@popvax.harvard.edu> mohamed@popvax.UUCP (R06400@Mohamed Ellozy) writes: >In article <2978@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: >> >>The "official" fix was posted in comp.bugs.4bsd.ucb-fixes a couple of weeks >>ago. >> >Has any expletive deleted vendor done anything official about it? Or is it >just tough luck for sites that run UNIX and do not follow the net? I'm not sure about other vendors, but Digital will supposedly include fixed versions of ftpd and fingerd in Ultrix V3.0. fingerd was not included at all in Ultrix V2.x, and the sendmail in V2.x does not have the DEBUG problem. The ftpd problem does exist, but with a few minor patches the code posted to comp.bugs.4bsd.ucb-fixes will work just fine under Ultrix. --Pat.
dave@onfcanim.UUCP (Dave Martindale) (12/08/88)
In article <22234@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: > >If you have constructive suggestions on how a vendor could release free >fixes for things like the sendmail or ftpd bugs without getting in >trouble with the Internet Police, with customers who pay for support, >with whose who don't have the target machine and don't want to pay for >the bandwidth, and with those who pay the bills, please let me know. SGI >has found nothing that works. > > >Vernon Schryver >Silicon Graphics >vjs@sgi.com How about providing UUCP connections for sites that have support contracts? I would certainly be willing to set up such a connection if SGI offered, and in fact we do have a direct uucp connection to a couple of other vendors. If a major bug is discovered, the vendor could put the repaired binaries into ~uucp or other "public" directory and then send mail to sysadmins telling them it's there. I'd even be willing to pay for the phone call. I realize that this would require a good-sized machine and lots of modems for a vendor of any size. However, I suspect it would be a relatively small fraction of the money that is paid for support each year. Imagine the increase in customer loyalty if customers felt that their vendor cared enough about them to inform them, individually, about bugs and fixes. Currently, the customer has to waste the time required to trip over a bug, verify that it was indeed the vendor's problem, call the support phone number, wait for a return call, have the fact that the vendor knows about the bug verified, and then wait another year before it is fixed "in the next release".