Re: [SC-L] Programming languages used for security
At 11:38 AM -0700 7/13/04, Blue Boar wrote: >ljknews wrote: >> The environment with which I am most familiar is VMS, and tradition >> is what guides secure interfaces. Inner mode code _must_ probe any >> arguments provided from an outer mode, probe the buffers specified >> by descriptors provided, etc. > >What do you do when you're handed a bad pointer? Return SS$_ACCVIO. -- Larry Kilgallen
Re: [SC-L] Programming languages used for security
>> The environment with which I am most familiar is VMS, and tradition >> is what guides secure interfaces. Inner mode code _must_ probe any >> arguments provided from an outer mode, probe the buffers specified >> by descriptors provided, etc. > What do you do when you're handed a bad pointer? I forget whether it's returning an error code analogous to EFAULT or raising an access violation, but I'm fairly sure it's one of them (at least under the versions I used). Either would be reasonable, the latter arguably more so (just as under Unix, it would arguably be more sensible to generate a SIGSEGV/SIGBUS rather than returning EFAULT). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
RE: [SC-L] Risk Analysis: Building Security In #3
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of ljknews > Sent: Tuesday, July 13, 2004 8:37 AM Larry Kilgallen wrote... > At 5:30 PM -0600 7/12/04, Jared W. Robinson wrote: > >I read the paper, and found it interesting. I read the statistic "50 > >percent of security problems are the result of design > flaws". Where does > >that number come from? Experience? > > I would say it comes from sloppy wording. > > At best, the author might discuss "50 percent of security problems > discovered to date...". Back as late as either 1998 or 1999, approximately 50% of the CERT advisories were attribued to security issues caused by buffer overflows. Now I certainly wouldn't count buffer overflows as DESIGN errors, but some people might. Likewise, I probably wouldn't count most data validation-related errors (specifically, the lack thereof) as design errors, but again, some people might. If those reporting this statistic were of that ilk, I could see the number being close to 50%. But in my experience from the past 5 years (through code inspections, pen testing, etc.), in my small sample of the world, that number has been closer to 20-25%. (But that could be because we develop in Java or C#; no more C or C++.) But, numbers such of these, in absence of any context of how the figures were derived are IMHO, close to meaningless. -kevin wall --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 "The difference between common-sense and paranoia is that common-sense is thinking everyone is out to get you. That's normal -- they are. Paranoia is thinking that they're conspiring."-- J. Kegler
Re: [SC-L] Programming languages used for security
ljknews wrote: At 11:38 AM -0700 7/13/04, Blue Boar wrote: ljknews wrote: The environment with which I am most familiar is VMS, and tradition is what guides secure interfaces. Inner mode code _must_ probe any arguments provided from an outer mode, probe the buffers specified by descriptors provided, etc. What do you do when you're handed a bad pointer? Return SS$_ACCVIO. So you put in an error handler that catches access ciolation before you try to use the pointer? OK, fair enough. What if the pointer points to memory you own, but not the right kind? I have always been under the impression that raw pointers could always cause you problems. I've assumed that a secure language would have to eliminate that as a type. BB
Re: [SC-L] Programming languages used for security
At 10:39 AM -0700 7/14/04, Blue Boar wrote: >ljknews wrote: > >> At 11:38 AM -0700 7/13/04, Blue Boar wrote: >> >>>ljknews wrote: >>> The environment with which I am most familiar is VMS, and tradition is what guides secure interfaces. Inner mode code _must_ probe any arguments provided from an outer mode, probe the buffers specified by descriptors provided, etc. >>> >>>What do you do when you're handed a bad pointer? >> >> Return SS$_ACCVIO. > >So you put in an error handler that catches access ciolation before you try to use >the pointer? OK, fair enough. What if the pointer points to memory you own, but not >the right kind? The inner mode code probing ensure that the calling mode has the ability to read and/or write the memory (according to the semantics of the particular interface. The inner mode code does not distinguish between stacks and various heaps, just that the memory is readable or writable by the calling process in the mode from which the call is made. > I have always been under the impression that raw pointers could always cause you > problems. I've assumed that a secure language would have to eliminate that as a > type. As have I. -- Larry Kilgallen
