size we receive here should fit into the receive buffer. Unfortunately,
there's no 100% foolproof way to distinguish a ridiculously large record
size that a client actually meant to send us from a ridiculously large
record size that was sent as a spoof attempt.
The one value that we can positively identify as bogus is zero. A
zero-sized record makes absolutely no sense, and sending an endless
supply of zeroes will cause the server to loop forever trying to
fill its receive buffer.
Note that the changes made to readtcp() make it okay to revert this
sanity test since the deadlock case where a client can keep the server
occupied forever in the readtcp() select() loop can't happen anymore.
This solution is not ideal, but is relatively easy to implement. The
ideal solution would be to re-arrange the way dispatching is handled
so that the select() loop in readtcp() can be eliminated, but this is
difficult to implement. I do plan to implement the complete solution
eventually but in the meantime I don't want to leave the RPC library
totally vulnerable.
That you very much Sun, may I have another.
recently in BUGTRAQ. The set_input_fragment() routine in the XDR record
marking code blindly trusts that the first two bytes it sees will in fact
be an actual record header and that the specified size will be sane. In
fact, if you just telnet to a listening port of an RPC service and send a
few carriage returns, set_input_fragment() will obtain a ridiculously large
record size and sit there for a long time trying to read from the network.
A sanity test is required: if the record size is larger than the receive
buffer, punt.
so that all these makefiles can be used to build libc_r too.
Added .if ${LIB} == "c" tests to restrict man page builds to libc
to avoid needlessly building them with libc_r too.
Split libc Makefile into Makefile and Makefile.inc to allow the
libc_r Makefile to include Makefile.inc too.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
- 64 bit long type safe (wire protocols specified in explicit sized types)
- Support systems that don't do unaligned accesses
- Support for explicit int16 and int32 sizes in xdr
Obtained from: a diff of FreeBSD vs. OpenBSD/NetBSD rpc code.
