Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Keeping Solaris up-to-date: summaryJohn RIddoch (jrSCMS.RGU.AC.UK)
Wed, 20 Jan 1999 10:15:24 +0000
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ollie Whitehouse: "FW: Personal web server - Temporary Fix"
- Previous message: Luke Mewburn: "NetBSD Security Advisory 1999-001: select(2)/accept(2) race"
As promised, here is a summary of comments from BUGTRAQ readers: Robert Watson raised an issue about a potential race condition while the script reads the file data in. If the file is modified during the running of the script, inconsistent data is likely to be read. While there is no obvious exploit to this, it is still considered a bug. Some kind of file-locking could be implemented to prevent this, especially since all hosts are Solaris machines. He also raised the issue that NFS is not cryptographically protected and is not a particularly secure transport. Several people asked about brining the system down to single user mode (as is recommended, especially for kernel patches). No, I haven't looked at that as yet, although I may consider trying to implement it. However, I haven't experienced any problems with applying patches to live systems as yet. Everett Lipman raised concern about running an NFS-mounted script, as it becomes trivial to break root on multiple machines if the NFS server is cracked. The obvious fix is to install the script on each machine (say, in /usr/sbin). He also pointed out that the NFS-server could share the directory read-only for added safety. This was, in fact, what I had done (although I didn't mention it). Corey Lindsly also pointed out that blithely applying patches can be a Bad Thing as patches have been known to break systems. Finally, something which no-one actually pointed out to me was that there is no checking of the data read in from the patch_list file; simply having a line: 123456-12;rm -rf / would delete the machine (the danger of using system() calls). I plan on implementing bounds checking this in the script. Finally, I've put the stuff regarding this on the web at http://www.scms.rgu.ac.uk/staff/jr/computing/unix/perl/patchupdate.shtml This includes the issues raised above and some better instructions on how to install and set up the script. Any further updates will be posted there. -- John Riddoch Email: jrscms.rgu.ac.uk Telephone: (01224)262730 Room C4, School of Computer and Mathematical Science Robert Gordon University, Aberdeen, AB25 1HG "Yoda of Borg are we: Futile is resistance. Assimilate you, we will"