[576] in Athena Bugs
[George P. Lekkas: setsockopt(2) behaviour in BSD sockets.]
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon Aug 1 22:53:03 1988
Date: Mon, 1 Aug 88 22:51:59 EDT
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
This message claims to have a way to crash 4.3BSD; maybe we should
look into this...?
------- Forwarded Message
From: <raeburn@ATHENA.MIT.EDU>
Date: Thu, 21 Jul 88 03:54:53 EDT
To: raeburn@ATHENA.MIT.EDU
Path: bloom-beacon!tut.cis.ohio-state.edu!rutgers!ucsd!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!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.
------- End Forwarded Message
