Path: utzoo!attcan!uunet!mcvax!cernvax!lekkas From: lekkas@cernvax.UUCP (George P. Lekkas) Newsgroups: comp.bugs.4bsd Subject: setsockopt(2) behaviour in BSD sockets. Summary: users shouldn't be able to crash the system Message-ID: <758@cernvax.UUCP> Date: 18 Jul 88 15:27:45 GMT Reply-To: lekkas@cernvax.UUCP (George P. Lekkas) Organization: CERN, Geneva, Switzerland Lines: 40 A question concerning the setsockopt(2) call. First I remind you that: getsockopt, setsockopt - get and set options on sockets setsockopt(s, level, optname, optval, optlen) int s, level, optname; char *optval; int optlen; When manipulating socket options the level at which the option resides and the name of the option must be specified. To manipulate options at the socket level, _l_e_v_e_l is speci- fied as SOLSOCKET. To manipulate options at any other level the protocol number of the appropriate protocol con- trolling the option must be supplied. For example, to indi- cate an option is to be interpreted by the TCP protocol, l_e_v_e_l should be set to the protocol number of TCP. For further information, see getprotoent(3n). Trying to figure out how Internet sockets work/behave and watching them closely, I decided to do a setsockopt at the TCP protocol level, that is set the level=6. This call was made on the socket returned from accepting a connection request, at the server side. All sockets were of the SOCK_STREAM type and you can find this typical client/server paradigm in the 4.3BSD Communications Primer. Just add the setsockopt(msgsock,..) call after the msgsock = accept() line. Optval and optlen were set to zero, optname can be 0 or SO_DEBUG. It is not clear whether this kind of call is supposed to produce output of any kind. My question and remark is on the result: A simple user can cause a VAX (8530 on Ultrix 2.0-1 and 750 on 4.3BSD) to crash ("protection trap 9" or something) Should this be so easy ? Is there a patch for it ? That is the question. I know this is not a bug report, but I hope it's enough for someone to answer me. George Lekkas lekkas@theseas.uucp NTUA, Athens, Greece, lekkas@cernvax.uucp CERN-SPS Div., Geneva, Switzerland.