Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #45795
| Subject | Re: Avoiding memory access vulnerabilities |
|---|---|
| References | <2016Feb26.143842@mips.complang.tuwien.ac.at> |
| Newsgroups | comp.lang.forth |
| From | "Elizabeth D. Rather" <erather@forth.com> |
| Organization | FORTH, Inc. |
| Date | 2016-03-02 21:18 -1000 |
| Message-ID | <Z9SdnbI2B6b5eErLnZ2dnUU7-R3NnZ2d@supernews.com> (permalink) |
On 2/26/16 3:38 AM, Anton Ertl wrote: > A frequent source of vulnerabilities in C is buffer overflows: A > memory access can happen outside the bounds of an array or otherwise > outside the bounds of an object (C terminology, in Forth standard > terminology the relevant term is "contiguous region"); the classic > case is to have a store that overwrites the return address adjacent to > the buffer and leads to arbitrary code execution (in Forth return > addresses are typically not close to buffers, but just consider a > variable or field containing an xt close to the buffer, so Forth is > not immune to that). Or the buffer overflow could be a memory fetch > of data that is then sent to the attacker (the heartbleed > vulnerability was of this type, helped along by overzealous > "optimization"). > > The typical idea of C and Forth programmers with respect to this kind > of danger is to take more care when programming, so that the > vulnerability is avoided. But that has not worked for C programs, and > I guess it does not work for Forth programs, either, at least for big > ones. Programmers also want to avoid bugs by taking care, but somehow > bugs tend to creep into programs. In the Forth community we tend to > find bugs by testing, but vulnerabilities often don't show up in > regular testing, and I don't think there is a testing regime that is > guaranteed to find all memory-access vulnerabilities. > > So what else can we do? The idea I am going to explore here is to > limit the part where you have to take special care to a small part of > the program; that goes nicely with the idea that you write an > application-specific wordset and use that to program the application. > > The idea is to make the memory access words that take arbitrary > addresses (@ ! c@ c! etc.) only visible in the small special-care > parts, and use more restricted replacements for these words in the > rest of the program. E.g., one could make them visible with INSECURE > and make them invisible with SECURE. The programmers are responsible > themselves for not making these words available through aliases, > deferred words, etc., and of course for not putting vulnerabilities in > the INSECURE code. > > How would the replacements look? > > Arrays: here one would have words that take an array descriptor and > index, and perform an index check before performing the fetch or > store. Maybe TH@ TH!, or, based on the FSL, }@ }! (just examples, one > would need a full complement for various types and number of array > dimensions; hmm, this appears to become a large number of words; what > can one do about that?). For iterating over arrays, one would have > macros that iterate from one index to another, delivering one element > per iteration, to make it possible to do the bounds check once instead > of once per iteration. Maybe some more common cases of iterating over > arrays can be optimized with special words or macros. > > Simple variables: Actually here the checking is not so important in > principle, because one does not buffer-overflow on V @ or V !. > However, because @ and ! are not visible, and we don't want people to > misuse their replacements, the replacements should be able to do > run-time checks in principle, with the option to disable the checks > after testing; (in contrast to arrays, one can test variable accesses > exhaustively). My idea is to have words @v !v c@v c!v etc., that can > access only variables (checked at run-time by comparing a signature > field beside the data field). The signature is filled with a random > value. Alternatively, one could use a dot-parser recognizer that > accepts V.@ V.! if V is a variable. > > Structure fields: Like for variables, the checking is not as essential > as for arrays here, but we have to replace @ ! etc. Let's assume a > structure S with a field F. Typical source code patterns are to have > F @, F !, @ F, or ! (where the stored value points to an S). One > could have a dot-parser that recognizes F.@ F.! @.F and S.! for these > patterns. One could have an option to add a signature field to a > structure, and let the generated code check the signature of the > involved structure. This could actually be quite useful in debugging, > not just for security. > > MOVE FILL etc.: One might consider these words secure, because you > pass it the buffer size anyway. However, at least for MOVE the passed > size is derived from the source buffer size and may exceed the target > buffer size; or one uses some address arithmetic for determining the > address and size for FILL, which may also incur errors. So one could > have replacements for these words that take a buffer descriptor and > offset/address for the target, and checks that all accesses performed > lie within the target. I am not sure about this, but the C11 standard > has added variants of many library functions with the target buffer > size as additional parameter (e.g., memmove_s() as > memmove()-replacement). > > What is there to do? Refine this sketch some more, do a prototype > implementation, and try how well this idea works when one is > programming, and how much the overhead of checking is (for the > required array checks, and for the optional variable and field > checks). I have been following this discussion with interest, but remain somewhat mystified. I don't know much about C, but a fair amt about Forth. Among the things I know about Forth is that implementations vary dramatically: from the obvious distinction between ITC, DTC, STC, and compile-to=code, to dictionary organization (e.g. data space separated from code space or intermingled; header arrangement, ... ). With all these variances, what kinds of vulnerabilities does "Forth" (per se) have? Let's assume for the moment that I want to write an attack on a Forth program, using a buffer overflow error. I have a bit of code (machine language) that does the bad thing I want to do, and I want to con some Forth program into branching to it. How would I do that? How does managing to store outside a defined buffer area achieve any of my malevolent intentions? Given the incredible variety of Forth implementations, how can any of my assumptions work for more than one particular known implementation (swiftForth, eForth, figForth, VFX, gForth, jonesForth, one-off experiments, ... )? Let us assume you, a baddie, want to attack a particular program, a production code widely released (else, why bother?). How do you find out what implementation it is? Which release? How its data spaces and code spaces are arranged? Assuming you can write some code that declares a buffer and then tries to store beyond its memory. How do you deliver the address to the Forth system to cause it to be executed? Let's assume you know Forth pretty well. Do you want to push the address of your evil code on the Return Stack? If so, do you know how RStack addresses are accessed? How do you do this push, anyway, since you don't know where the Return Stack pointer is (in a register, and if so, which, and assuming what kind of jump? In memory? Where?) What is its format (machine code, dtc addresses, stc addresses, mixture, ... )? There's a lot of folklore about attacks that assume C code, because it's ubiquitous, but I'm not at all sure these attacks would get far against more than one Forth program (and that assumes knowledge of which Forth that program is and how its Forth worked at that point in time). Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-26 13:38 +0000
Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-26 16:05 +0000
Re: Avoiding memory access vulnerabilities Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-26 17:18 -0500
Re: Avoiding memory access vulnerabilities Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-02-26 22:53 -0800
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 07:15 +0000
Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-27 04:54 -0600
Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-02-27 14:27 +0000
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 15:31 +0000
Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-01 16:30 +0000
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 10:04 +0000
Re: Avoiding memory access vulnerabilities Doug Hoffman <glidedog@gmail.com> - 2016-03-02 08:41 -0500
Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-02 23:22 +0000
Re: Avoiding memory access vulnerabilities humptydumpty <ouatubi@gmail.com> - 2016-03-02 22:57 -0800
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 13:50 +0000
Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 21:01 +0000
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 10:55 +0000
Re: Avoiding memory access vulnerabilities Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-27 11:31 -0500
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 17:14 +0000
Re: Avoiding memory access vulnerabilities Ron Aaron <rambamist@gmail.com> - 2016-02-27 18:59 +0200
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 17:04 +0000
Re: Avoiding memory access vulnerabilities Ron Aaron <rambamist@gmail.com> - 2016-02-27 19:18 +0200
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-28 14:21 +0000
Re: Avoiding memory access vulnerabilities "Elizabeth D. Rather" <erather@forth.com> - 2016-03-02 21:18 -1000
Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-03 10:23 +0000
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 14:22 +0000
Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-03 04:53 -0600
Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-03 13:15 +0000
Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-04 04:34 -0600
Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-04 04:56 -0600
Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-04 12:07 +0000
Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-04 09:48 -0600
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:11 +0000
Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-04 11:55 +0000
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 11:33 +0000
Re: Avoiding memory access vulnerabilities Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-04 20:55 -0500
Re: Avoiding memory access vulnerabilities Mark Wills <markwills1970@gmail.com> - 2016-03-05 02:55 -0800
Re: Avoiding memory access vulnerabilities "Elizabeth D. Rather" <erather@forth.com> - 2016-03-10 22:39 -0800
Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 12:44 +0000
csiph-web