Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #24331
| Date | 2013-07-09 12:02 -1000 |
|---|---|
| From | "Elizabeth D. Rather" <erather@forth.com> |
| Organization | FORTH, Inc. |
| Newsgroups | comp.lang.forth |
| Subject | Re: WWW-safe Forth? |
| References | (8 earlier) <krbhv4$dm5$1@speranza.aioe.org> <a46aa97a-faa0-4dfc-a7c7-1caed4f765fc@googlegroups.com> <kredus$lsg$1@speranza.aioe.org> <9P-dnY5wTdNgtkbMnZ2dnUVZ_ridnZ2d@supernews.com> <krhtud$65r$1@speranza.aioe.org> |
| Message-ID | <WI2dncHJ98zEFUHMnZ2dnUVZ_oudnZ2d@supernews.com> (permalink) |
On 7/9/13 11:09 AM, Rod Pemberton wrote: > "Elizabeth D. Rather" <erather@forth.com> wrote in message > news:9P-dnY5wTdNgtkbMnZ2dnUVZ_ridnZ2d@supernews.com... >> On 7/8/13 3:18 AM, Rod Pemberton wrote: >>> "Howerd" <howerdo@yahoo.co.uk> wrote in message >>> news:a46aa97a-faa0-4dfc-a7c7-1caed4f765fc@googlegroups.com... >>>> On Sunday, July 7, 2013 1:08:30 PM UTC+2, Rod Pemberton wrote: > >>> The first part of the idea that you can't both eliminate all >>> the insecure primitives and also have enough system words >>> for the interpreter to function. >> >> The entire system is perfectly capable of functioning under a >> security layer implemented as a sealed wordlist. The fact that >> words are not accessible by name doesn't mean they no longer >> exist or function, and the fact that there is no user access to >> code space doesn't mean it doesn't exist and function. >> > > Exactly. > > The only problem is that you're looking at this indicating that the > system is secure, when it actually indicates the system is > insecure. > > If "words are not accessible by name doesn't mean they no longer > exist or function", then those words can possibly be accessed by a > hacker. If "no user access to code space doesn't mean it doesn't > exist and function", then that functionality could still be used by > a hacker. Preventing hacking and ensuring security is about > preventing the possibilities of unintended or unintentional access. > I.e., you must start from the perspective that the hacker has or > will find a way to access everything available in the system. You have to determine who your intended users are, and what is the worst-case scenario. If your intended users are a limited set and the worst that can happen is that the computer running the Forth needs to be restarted, your level of defensiveness is different from a public facility or the Department of Defense. But you also need to know a little more about the nature of Forth and the sealed vocabulary mechanism I'm proposing. For example, how would a hacker find out the names and locations of insecure words that are not in the public wordlist? Every implementation does these underlying things differently, so the names would be different, and every specific platform would put them at different locations. Assume DUMP is not available (which it wouldn't be in this scenario)? >>> This is based on the premise that the high level words are >>> coded entirely using low level words which can be thoroughly >>> vetted. Forth's which have high level words that have code >>> that isn't a part of some other high or low level Forth word >>> are more vulnerable, e.g., compiled directly to assembly. The >>> code that's generated for that word, which isn't part of >>> another high or low level Forth word, can't be tested for >>> insecurity. >> >> Sure it can. Whether a word (internal to the system) is defined >> in high level, code, or C is immaterial. > > No, it's not. > > E.g., you know full well that I use C strings. You probably didn't > know I use C's string functions too. Many of C's string functions > are subject to buffer overflow issues which could allow > unauthorized code execution. The way these work is that the hacker > writes a text string to a location on the stack. Then, the hacker > triggers the buffer overlow. The result of that is that execution > transfers to the string. I.e., in Forth terms this hack modified > the return address on the return stack, just like some words in > interpreted Forths adjust saved return data. This "error" is built > into C's string functions, in fact some of these errors are > "mandatory", i.e., required by the C specifications. As long as I > chose to use those functions, I can't eliminate the bug. But, I > also can't be aware of every bug present in C code, or the OS code > either. So, this potential attack, and potentially others, is > present in my Forth system too, even if direct access to it is > denied to the hacker. The hacker just needs to know it's there. > This means that there might be one or two or three etc additional > steps that a hacker needs to do to cause such an overflow in the C > code in my Forth system. But, if the hacker knows how to implement > such an attack, then they just need to figure out how to get past > the Forth to get to it. I.e., since the fault is present in the > system, it's just a matter of how to access it. An excellent reason to avoid using C strings and string functions in your secure Forth! >>>>> There are too many low-level words. >>>> >>>> Are high level words somehow more secure? I think not. >>> >>> That depends on how they're coded. If the high level words use >>> assembly, then high level words can be made insecure too via >>> assembly. It high level words only use low level words, then >>> high level words depend on the safety of the available low >>> level words. >> >> You're really missing a major point here. Can you provide an >> example of this? Assume in writing your example that you can >> only access high level Forth words that have been made available >> in the restricted wordlist and can only store into authorized >> data space. > > I think you're missing a major point too: hacking is about finding > _any_ way to execute unauthorized code by _any_ means necessary, > not just the provided or authorized methods of execution, and not > just what's present in Forth. Think of this as someone in the > middle ages attempting to breach a castle, where Forth is just the > moat. You've just described a common scenario for hacking a C program. Now, consider a Forth system in which only a limited subset of words are visible in the wordlist. These do not include DUMP or any access to code space, and limited access to data space. You do not know the implementation strategy (e.g. ITC, optimized code, etc.). And the implementer is too smart to use C strings because he knows they're vulnerable. So, what kind of hack are you concerned about? > If there is a way to directly execute code which is provided to the > user, then the hacker will use that. If there is a way to exploit > functionality of the system to execute code via an unintended > pathway, then the hacker will use that. If there is a way to > exploit a crash or bug in the system, then the hacker will use > that. I.e., the only way to eliminate the possibility of a breach > entirely is to not execute anything. Since that's not a > possibility, the next best option is to eliminate as much > functionality as possible so the hacker can't access supposedly > inaccessible functionality. Finally, whatever functionality must > be present needs to be reviewed in it's entirety for safety. > Unfortunately, people can't foresee all possible methods of attack. > That implies there is a potential breach point, or many of them, > remaining. Those are generalized assertions. My question is, how would you approach doing any of these things in the Forth I described above? > I.e., even if there is a sealed vocabulary, you should expect the > hacker to be able to find a method to execute functionality within > it. I.e., if the Forth environment calls the OS, perhaps for GUI > or text input, you should expect the hacker to find and abuse bugs > within it. How would you even know whether the Forth calls the OS, or whether there is an OS (vs. a native Forth)? All you're doing is asserting that it's possible, without any clue how. Unless you can look at actual potential attack strategies, it's impossible to have a fruitful discussion of possible defenses. >> [SNIP, revisit SMUDGEd XT] > > In the snipped portion of the conversation, you asked about how a > user would find an XT that's hidden. Well, I mentioned > shotgunning, i.e., testing a range of values assumed to be correct, > based on the first and last WORDS in a dictionary. But, an XT > could also be known in advance. E.g., I have gforth-itc v0.7.0 > installed on my system. It *ALWAYS* returns an XT for BYE of > 416128432. This is true even with multiple windows. I can enter > 416128432 directly and type EXECUTE and BYE will EXECUTE. That assumes, first, that you know the Forth you're using is gforth-itc v0.7.0 and second, that EXECUTE is available to you. It's probable that neither is true. Certainly EXECUTE is one of the words that I would *not* include in a sandboxed Forth! > Almost unbelievably, this is true across reboots. This implies > that value is hardcoded to that binary. So, there's a chance this > is true across multiple systems too. I.e., I most likely know the > XT for BYE for gforth-itc v0.7.0 running on your system (if you're > running it...) or someone else's system. If that's the case, the > XT is known, in advance. The hacker doesn't need ' (tick) or FIND. > They can type the value in directly. This seems to be true for > bigFORTH and Win32Forth as well. If it's SMUDGED (or HIDE), it's > still a known XT. Typing in the value for EXECUTE even when > SMUDGED will EXECUTE that value. If it's in a different dictionary > or sealed vocabulary, the hacker will or may need a hack to access > that dictionary or vocabulary, but once they've got that hack, the > XT is known and they can execute it. They could also shotgun the > location and range of the other dictionaries or vocabularies, e.g., > they could assume it's in memory just before or after the one they > have access to. They'd probably be correct. > > Of course, that's just executing Forth XTs, as mentioned > previously, a text string and a method to transfer execution to > code would allow x86 code to executed. A bug in other code, like > the OS or system libraries, can be used to breach as well. The > hacker is looking for any method that works. The question was, how would you make a "sandboxed" Forth available on the internet. We have a bunch of considerations already, including a limited, sealed vocabulary whose words can only directly access an authorized region of data space. Assuming that all the user knows is the url to access it, it's reasonable to assume that the user would also have a very hard time finding out what version of Forth, what implementation strategy, under what OS, or any other features that would clue you in to a vulnerability. For all you know, it isn't even an x86 underneath. 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
WWW-safe Forth? papa@sdf.lNoOnSePsAtMar.org (David Meyer) - 2013-07-05 19:24 +0000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-05 13:37 -0700
Re: WWW-safe Forth? papa@sdf.lNoOnSePsAtMar.org (David Meyer) - 2013-07-05 21:17 +0000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-05 15:22 -0700
Re: WWW-safe Forth? papa@sdf.lNoOnSePsAtMar.org (David Meyer) - 2013-07-06 01:56 +0000
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-06 14:42 +0200
Re: WWW-safe Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-06 07:56 -0500
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-07 01:11 +0200
Re: WWW-safe Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-07 02:44 -0500
Re: WWW-safe Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-07 10:28 +0000
Re: WWW-safe Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-06 13:42 +0000
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-07 01:40 +0200
Re: WWW-safe Forth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-05 20:20 +0000
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-06 12:41 -0400
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-06 12:03 -0700
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-06 12:41 -0700
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-06 14:01 -0700
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-06 14:26 -0700
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-06 12:32 -1000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-06 19:58 -0700
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-06 18:14 -1000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-06 21:51 -0700
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-06 21:01 -1000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 00:36 -0700
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-07 01:25 -0700
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 01:56 -0700
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-07 08:34 -1000
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-07 07:08 -0400
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-07 08:41 -1000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 12:59 -0700
Re: WWW-safe Forth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-07 20:18 +0000
Re: WWW-safe Forth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-09 01:09 +0000
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-08 00:09 +0200
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 18:15 -0700
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-07 17:22 -1000
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-07 17:20 -1000
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-07 13:13 -0700
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 14:02 -0700
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-08 01:25 +0200
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 18:26 -0700
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-09 19:21 +0200
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-10 01:55 -0700
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-10 23:51 +0200
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-07 21:10 -0700
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 22:03 -0700
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-07 22:27 -0700
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-08 00:30 -0700
Re: WWW-safe Forth? Hannu Vuolasaho <hannu.vuolasaho@nospam.tut.fi.invalid> - 2013-07-08 13:08 +0000
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-08 09:18 -0400
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-08 07:02 -0700
Re: WWW-safe Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-08 09:46 -0500
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-08 11:04 -0700
Re: WWW-safe Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-08 12:49 -0500
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-08 11:26 -0700
Re: WWW-safe Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-08 16:28 -0500
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-08 11:15 -1000
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-09 17:09 -0400
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-09 12:02 -1000
Re: WWW-safe Forth? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-07-10 23:52 +0200
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-12 03:04 -0400
Re: WWW-safe Forth? gavino_himself <visploveslisp@gmail.com> - 2013-07-28 02:32 -0700
Re: WWW-safe Forth? gavino_himself <visploveslisp@gmail.com> - 2013-07-27 22:18 -0700
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-12 03:31 -0400
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-11 23:03 -1000
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-14 18:15 -0400
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-14 13:50 -1000
Re: WWW-safe Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-15 14:12 +0000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-15 10:22 -0700
Re: WWW-safe Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-15 17:07 +0000
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-17 01:12 -0700
Re: WWW-safe Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-17 09:43 +0000
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-17 15:04 +0200
Re: WWW-safe Forth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-17 13:50 +0000
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-15 07:57 -1000
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-15 22:45 -0400
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-15 18:21 -1000
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-15 07:52 -1000
Re: WWW-safe Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-16 16:15 +0000
Re: WWW-safe Forth? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-16 08:17 -1000
Re: WWW-safe Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-17 09:33 +0000
Re: WWW-safe Forth? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-15 22:40 -0400
Re: WWW-safe Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-10 03:26 -0500
Re: WWW-safe Forth? Howerd <howerdo@yahoo.co.uk> - 2013-07-07 01:46 -0700
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 02:39 -0700
Re: WWW-safe Forth? AKK <akk@nospam.org> - 2013-07-07 11:56 +0200
Re: WWW-safe Forth? Paul Rubin <no.email@nospam.invalid> - 2013-07-07 03:20 -0700
Re: WWW-safe Forth? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-07 01:21 +0200
Re: WWW-safe Forth? Hans Bezemer <the.beez.speaks@gmail.com> - 2013-07-09 23:22 +0200
Re: WWW-safe Forth? gavino_himself <visploveslisp@gmail.com> - 2013-07-27 21:34 -0700
csiph-web