IMO, who cares about being able to crash AS this way? The only scenario I can see it being important is for a hosting service that lets users interact directly with TCL. I doubt there are very many of those. And if it's a big concern there, those sites can easily redefine ns_rwlock to add array lookup and protection before calling the real ns_rwlock.
Jim > > In a message dated 8/29/02 11:48:19 PM, [EMAIL PROTECTED] writes: > > > > Date:=A0 =A0 Thu, 29 Aug 2002 15:46:57 +0100 > > From:=A0 =A0 Harry Moreau <[EMAIL PROTECTED]> > > Subject: How to crash AOLserver 3.4 in one line of tcl... > >=20 > > The line is > >=20 > > ns_rwlock destroy rid0x83daf50 > >=20 > > providing that rid0x83daf50 does *not* point to a valid rwlock, or a secon= > d > > example using three lines... > >=20 > > set lock [ns_rwlock create] > > ns_rwlock destroy $lock > > ns_rwlock destroy $lock > >=20 > > Attempting to destroy the lock (intentionally or otherwise) twice > > will crash the server. > >=20 > > This happens because... > >=20 > > There are two functions in nsd/tclthread.c to manage rwlocks, mutexes etc. > >=20 > > GetObj() and SetObj() > >=20 > > The first three bytes of the name of a rwlock/mutex/semaphore/condvar etc > > are interpreted as the type identifier, the rest of the rid0x83daf50 strin= > g > > above is assumed to be the actual address of the thing!=A0 No further=20 > > checking > > is performed by GetObj() to ensure that the provided address is actually > > correct, so you can make up any address you like and pass it to ns_rwlock=20 > > or > > ns_mutex or whatever with the destroy sub-command and have the memory so > > pointed to over-written! > >=20 > > I looked at the 4.0 beta code, this hasn't changed.=A0 I'm going to fix it= > =20 > > for > > my sites - haven't decided how yet - I'll be quite happy to pass on the=20 > > code > > to someone for review and possible inclusion in the code base. > >=20 > >=20 > > > Hi, > > Old versions of AOLserver (prior to 2.3?) would maintain thread object ids i= > n=20 > a hash table protected by a mutex. We moved to direct address id's as part= > =20 > of an overall effort to remove as many locks as possible - those old version= > s=20 > were subject to a lot of lock contention. I recall describing this=20 > technique to Ousterhout a few years back - he thought is was a dumb idea. =20 > Oh well. > > Anyway, for 4.0 you could create some Tcl_Obj types which could lookup the=20 > addresses in a protected table and then store the result in the Tcl_Obj=20 > private data, avoiding the locks going forward. Send to me or upload to=20 > Sourceforge any patches you'd like to get integrated into the core. > > Thanks, -Jim >
