Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!melba!baby!gnb From: gnb@bby.oz (Gregory N. Bond) Newsgroups: comp.unix.wizards Subject: Re: Invalid Pointers (was Re: Referencing NULL pointers) Message-ID: Date: 28 Jul 89 04:03:23 GMT References: <20245@adm.BRL.MIL> <4348@eos.UUCP> <34785@bu-cs.BU.EDU> <12872@bloom-beacon.MIT.EDU> <35077@bu-cs.BU.EDU> Sender: gnb@melba.bby.oz Organization: Burdett, Buckeridge and Young Ltd. Lines: 26 In article <35077@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: Obvious attacks are 0 on many (but not all) systems, a pointer into text space on others (eg. the address of a function), even that depends on certain load options being used but we'll assume that's under control of the author, setting some magic bit (eg. pointing into the wrong P space on a VAX), others? For word-aligned machines, (e.g. 680x0), (int *)1. In fact, in one application involving humungous collections of 2D linked lists (linked plains??) I used (struct foo *)0 as uninitialised pointer, and (struct foo *)1 as initialised-to-invalid-address pointer. Both dumped core when dereferenced, and help track down obscure bugs. Especialy as I could do (struct foo *)(2*n+1) for any n, and work out which assignment was generating the pointer that was dereferenced. This method could give a very large class of distinguishable invalid pointers, (provided they weren't (char *)'s). Not a general solution, but neat for the problem I had. Greg. (No comp.lang.c in Australia. Lucky, hey?) -- Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb