Date: Sat, 2 Jun 2001 23:24:52 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: "Morgan Davis" <mdavis@cts.com>, "'Hajimu UMEMOTO'" <ume@mahoroba.org> Cc: <freebsd-stable@FreeBSD.org>, <security@FreeBSD.org>, <freebsd-print@bostonradio.org> Subject: RE: Malformed from address Message-ID: <p05100e00b73f51369492@[128.113.24.47]> In-Reply-To: <000801c0ebd3$932adae0$271978d8@cts.com> References: <000801c0ebd3$932adae0$271978d8@cts.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 7:19 PM -0700 6/2/01, Morgan Davis wrote: >Hajimu UMEMOTO writes: >> Then, Windows is broken. > >And, FreeBSD is also seriously outnumbered. > >> printer client must bind source port to within IPPORT_RESERVED. > >"Yeah, right." -- Bill Gates :-) Consider the example of lpr at RPI. We accept print jobs from hundreds of unix clients which are administered by "us" (the computer center). While we have control of administration of those machines, there are 5,000 to 10,000 people who can log into those same machines. We haven't figured out how to control those users... :-) Our print servers do accept jobs from those machines based on the hostname. That does not mean we want to allow all those thousands of users to *telnet* into lpd on the print servers, and send their own little fake jobs, just like you were doing in your testing. We do not accept jobs from many Windows hosts (not directly into lpd, that is). Almost all our windows users have to go thru samba, because we charge users for their printouts and we have be pretty confident that we KNOW the userid to charge to. [and for the few windows boxes we DO accept jobs from, we have some other RPI-specific changes so all jobs from those hosts are charged to a specific userid -- no matter what userid is listed in control-files for print jobs from that host. That's one of the changes I hope to sort out and incorporate into FreeBSD's lpr] So in our environment, there is absolutely no way we can allow connections from non-reserved ports. Not unless we make some major changes to lpd (which is always an option, given enough caffeine and a long enough weekend...). > > If you wish to allow such >> broken connection, you can simply remove reserved port checking. > >The restriction in lpd.c breaks printing from the vast majority >of computers in this neck of the galaxy. And, there's no fix, >other than for each admin to "simply" patch lpd.c, recompile, >and deploy throughout their enterprise? I can see that the reserved-port restriction might be problematic in other environments, particularly since it has not been enforced for the past four years. I also agree that administrators should not have to patch and recompile lpd to get the behavior they want. >I suggest that a compile-time option or a command line flag be >added so that the port checking is selectable. (My vote is for >a runtime flag that disables port checking or allows you to >specify your own acceptable range.) This is a reasonable "quick fix". I am in the middle of a rather involved update to lpr/lpd right this minute, but I'd be willing to add an option to lpd to specify if the administrator wants lpd to do the port checking. I could write something up for that within the next week. As a security matter, I think it should do the port checking by default, and the option would be to turn that checking off. If we take a little time to ponder the matter, a better (but more involved) fix would be to have two lists of allowed hosts. In my case, I can not afford to accept non-reserved-port connections from Unix hosts which we do administer, but we might want to allow that for other machines (such as windows boxes). Perhaps /etc/hosts.lpd and /etc/hosts.lpd-special or something. I would certainly have to think about it some more, and figure out what the best thing to do is. Thus, this would be something to consider as a longer-term improvement. >While I'm making lpd suggestions, it would be very nice if it >were smarter about using syslog or its own -d and -l capabilities >to truly log fatal() error messages, rather than spewing them >uselessly into stdout (or the socket stream). Hmm. Not sure what you mean here. At least at RPI, we DO get error messages in logfiles, at least for some kinds of errors. What do you have for 'lpr'-ish entries in your /etc/syslog.conf ? If there is a problem there, I could look into that too, but I would want to be a little careful that lpd won't open up any new denial-of-service attacks. >How many have been bit by clients that wouldn't print, only to >find that it was because they weren't in hosts.lpd, the client >IP addresses changed or a forward/reverse DNS error was >introduced, etc? I know that we have SOME logfile entries when hosts are not in hosts.lpd, for instance. Maybe we turn up logging, or maybe it's just some other difference between RPI's lpd and freebsd's. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05100e00b73f51369492>