Hello all,
I'm currently working on a TLS / SSL implementation and on windows I am planning to support the Certificate Store that is built in. This requires me to use the CryptoAPI dlls. The code is complex and it uses a number of header files and many steps. I built some C++ code that does what I'm looking for so now I would like to incorporate this into Squeak.
I'd assumed that FFI was like DDL/C connect in VW but that's not what I'm seeing. So my question is: What is the best way to get this working? Should I hack away at FFI and support the api directly, and is that even possible? Should I create DLL's to call and use them with FFI, or should I compile some sort of plugins? My preference would be to call the api directly without having to create dll's, duplicating my C++ code in Smalltalk if possible.
Some direction and comparisons of different options would be very helpful.
Thank you for your help!
Ron Teitelbaum
Well I've done all three, or is that four?
a) FFI class via platform specific instances interfacing to generic classes that a squeak user interacts with. b) FFI class/subclasses that are modified on the fly depending on platform to get module name correct and or provide overrides by platform, lots of this in Croquet. c) wrapper classes that use plugin code that lightly wraps api, support work all done in Smalltalk, I did this for the extended serial support. d) Generic classes that wrap plugin code that interfaces to platform specific code, lots of this in the VM
Issues. Generally getting folks to setup a development system, get VMMaker, understand plugins, build and test something is only done by a minority of squeakers.
In using FFI, mapping the parms/return values to the correct Smalltalk external objects will at some point drive you crazy, it does all work, but sometimes late at night you wonder. For the most part we do this in Sophie, any one can do FFI, but debugging is hard.
Using lightly wrap APIs, that provides a bit clearer, in my opinion, parameter specifications that then invoke the api. You usually can use the development system source debugger to halt and debug at the api inteface. It's a bit easy for folks to assemble features since they can code the steps in smalltalk and interface to the apis, new apis require someone to mangle plugin code and compile plugins. Technically it's very similar to FFI, but avoids FFI.
Using fully abstracted plugin with platform specific code, well that's hard, and few folks want to participate. You can of course write all the code via plugin code, I believe I do this for the mac menu bar plugin since it's platform specific, there is no platform C code, everything is done in squeak slang then compiled into the VM as the mac menu bar plugin (used in Sophie btw).
On 29-Jul-06, at 9:15 PM, Ron Teitelbaum wrote:
Hello all,
I’m currently working on a TLS / SSL implementation and on windows I am planning to support the Certificate Store that is built in. This requires me to use the CryptoAPI dlls. The code is complex and it uses a number of header files and many steps. I built some C ++ code that does what I’m looking for so now I would like to incorporate this into Squeak.
I’d assumed that FFI was like DDL/C connect in VW but that’s not what I’m seeing. So my question is: What is the best way to get this working? Should I hack away at FFI and support the api directly, and is that even possible? Should I create DLL’s to call and use them with FFI, or should I compile some sort of plugins? My preference would be to call the api directly without having to create dll’s, duplicating my C++ code in Smalltalk if possible.
Some direction and comparisons of different options would be very helpful.
Thank you for your help!
Ron Teitelbaum
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John,
Thank you very much for your response, it appears that you support DLL's to wrap and simplify Api's. This is doable but I wonder about maintainability and prefer not to push code outside of Smalltalk if possible for that reason. Although, I'm sure that it is the easier way to go, and probably the path I will take. Also given the cryptographic nature of the code that I'm writing and the need eventually to have the code certified, adding another level of code between the MS API and Squeak leaves another layer to protect.
Thanks again for giving me more to consider,
Ron Teitelbaum
From: John M McIntosh Sent: Sunday, July 30, 2006 2:26 AM
Well I've done all three, or is that four?
a) FFI class via platform specific instances interfacing to generic classes that a squeak user interacts with. b) FFI class/subclasses that are modified on the fly depending on platform to get module name correct and or provide overrides by platform, lots of this in Croquet. c) wrapper classes that use plugin code that lightly wraps api, support work all done in Smalltalk, I did this for the extended serial support. d) Generic classes that wrap plugin code that interfaces to platform specific code, lots of this in the VM
Issues. Generally getting folks to setup a development system, get VMMaker, understand plugins, build and test something is only done by a minority of squeakers.
In using FFI, mapping the parms/return values to the correct Smalltalk external objects will at some point drive you crazy, it does all work, but sometimes late at night you wonder. For the most part we do this in Sophie, any one can do FFI, but debugging is hard.
Using lightly wrap APIs, that provides a bit clearer, in my opinion, parameter specifications that then invoke the api. You usually can use the development system source debugger to halt and debug at the api inteface. It's a bit easy for folks to assemble features since they can code the steps in smalltalk and interface to the apis, new apis require someone to mangle plugin code and compile plugins. Technically it's very similar to FFI, but avoids FFI.
Using fully abstracted plugin with platform specific code, well that's hard, and few folks want to participate. You can of course write all the code via plugin code, I believe I do this for the mac menu bar plugin since it's platform specific, there is no platform C code, everything is done in squeak slang then compiled into the VM as the mac menu bar plugin (used in Sophie btw).
On 29-Jul-06, at 9:15 PM, Ron Teitelbaum wrote:
Hello all,
I'm currently working on a TLS / SSL implementation and on windows I am planning to support the Certificate Store that is built in. This requires me to use the CryptoAPI dlls. The code is complex and it uses a number of header files and many steps. I built some C ++ code that does what I'm looking for so now I would like to incorporate this into Squeak.
I'd assumed that FFI was like DDL/C connect in VW but that's not what I'm seeing. So my question is: What is the best way to get this working? Should I hack away at FFI and support the api directly, and is that even possible? Should I create DLL's to call and use them with FFI, or should I compile some sort of plugins? My preference would be to call the api directly without having to create dll's, duplicating my C++ code in Smalltalk if possible.
Some direction and comparisons of different options would be very helpful.
Thank you for your help!
Ron Teitelbaum
--
=== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Am 30.07.2006 um 06:15 schrieb Ron Teitelbaum:
Hello all,
I’m currently working on a TLS / SSL implementation and on windows I am planning to support the Certificate Store that is built in. This requires me to use the CryptoAPI dlls.
Well ... FFI is inherently unsafe - it allows to call any C function in any library. So depending on the area of application this might be a problem, since you're giving up the relative safety of a VM-based system. For example, if the VM's sandbox is enabled, FFI calls are disallowed, so you could not use crypto in a sandboxed environment.
- Bert -
Bert,
Thank you for your comments, I wasn't planning on using the sandbox since there are a number of external connections like Glorp-PostgreSQL needed where I plan to ultimately use this new functionality. I was hoping to address this with a signed image and VM. A signed image and VM could keep any changes out of the system.
The thing that concerns me is changes to a live system that happen without needing to save the image. Plenty can happen as the system is running so the question is: how can we secure the image while it is running?
Some things that would be needed off the top of my head are:
1) Disable file in 2) Disable the compiler for accepting or performing new code, but allow it for already coded performs. (I'm sure this is much easier said then done). 3) Disable interactive debugger. 4) Enable some sort of class level MAC checking which can verify that no changes were made to code before it is executed. 5) Prevent changes to compiled methods
Plus more that I'm sure will also be needed. If we can sign the image and VM and change the VM to check the signature before staring up and find a way to protect the live image then we will have gone a long way to having a more secure development platform.
I've mentioned this before and got absolutely no comment from anyone. (Maybe the email was too long to read?)
Some input would be very much appreciated.
Ron Teitelbaum
From: Bert Freudenberg Sent: Monday, July 31, 2006 12:37 PM Am 30.07.2006 um 06:15 schrieb Ron Teitelbaum:
Hello all,
I'm currently working on a TLS / SSL implementation and on windows I am planning to support the Certificate Store that is built in. This requires me to use the CryptoAPI dlls.
Well ... FFI is inherently unsafe - it allows to call any C function in any library. So depending on the area of application this might be a problem, since you're giving up the relative safety of a VM-based system. For example, if the VM's sandbox is enabled, FFI calls are disallowed, so you could not use crypto in a sandboxed environment.
- Bert -
On 31-Jul-06, at 1:18 PM, Ron Teitelbaum wrote:
- Disable the compiler for accepting or performing new code, but
allow it for already coded performs. (I'm sure this is much easier said then done).
If you're using the same terminology that I'm used to, you don't need the compiler to execute #perform: type messages. All that does is tell the vm to pretend that the relevant message had been sent in the usual way. Similarly for blocks.
Hmm, I should probably qualify that with a "unless someone has recently massively changed the system in a way that would render them a target of the 'Ninjas of Smalltalk Doom'".
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SFA: Seek Financial Assistance
Ron Teitelbaum wrote:
...
The thing that concerns me is changes to a live system that happen without needing to save the image. Plenty can happen as the system is running so the question is: how can we secure the image while it is running?
Some things that would be needed off the top of my head are:
- Disable file in
- Disable the compiler for accepting or performing new code, but allow it
for already coded performs. (I'm sure this is much easier said then done). 3) Disable interactive debugger. 4) Enable some sort of class level MAC checking which can verify that no changes were made to code before it is executed. 5) Prevent changes to compiled methods
Plus more that I'm sure will also be needed. If we can sign the image and VM and change the VM to check the signature before staring up and find a way to protect the live image then we will have gone a long way to having a more secure development platform.
I've mentioned this before and got absolutely no comment from anyone. (Maybe the email was too long to read?)
Some unstructured ideas from the top of my head: Securing a Smalltalk image is pretty difficult. The VM protects the system against a number of security holes such as buffer overflows etc. which would allow external attackers to compromise security. Protecting against internal attacks is much more difficult. If I were a computer security expert, I'd probably prefer an architecture where there is absolutely no possibility of adding new code to a running application. The Smalltalk image is *designed* to be the exact opposite of that :-) A truly secure VM/image combo would perhaps need to be done differently: The image should be split up into a read-only part containing classes and methods, and a writable part where the more mundane objects reside. Ideally, the read-only part would be protected using the hardware and OS mechanisms, so its integrity does not depend on the correctness of the VM and all its primitives. Of course, none of the development tools are supposed to be present in such an image, and even the hooks which they use should be carefully removed. There are some primitives (such as #become: and class-changing primitives) which a secure VM should either not implement or implement in a safer way. Checking the code integrity with checksums etc. is certainly a necessity. Linking to and depending on external code without checking its integrity as well is probably a no-no. Static linking is probably ok.
In any case, soothing the paranoia of security experts is going to be a difficult task. Once you know how many possibilities there are for tampering with software, you understand why...
Cheers, Hans-Martin
Hans-Martin,
Thank you for your thoughts!
I'm not sure the separation of code to isolate read only classes would be of much help since most of the problem lives in the memory model not in the stored code on disk. I would think that placing a certificate on the image file would be good enough "IF" we could prevent changes to the object structure and code in memory.
#become is a real problem since it is a very necessary part of proxy handling for almost all db interfaces I've worked with (including GLORP).
I wonder how much of this could be solved by on the fly checksums for everything. A few years ago this would have been impossible but with today performance is it really out of the question?
I agree with the need to remove the development tools.
As for the appeasing the security hacks: It's a nice challenge and I can tell you that "good enough security" is all anyone can ask for. If we set the bar too high we prevent advances in security that will do nothing but help to make a bad situation better.
Ron Teitelbaum
From: Hans-Martin Mosner Sent: Monday, July 31, 2006 4:50 PM
Ron Teitelbaum wrote:
...
The thing that concerns me is changes to a live system that happen
without
needing to save the image. Plenty can happen as the system is running so the question is: how can we secure the image while it is running?
Some things that would be needed off the top of my head are:
- Disable file in
- Disable the compiler for accepting or performing new code, but allow
it
for already coded performs. (I'm sure this is much easier said then
done).
- Disable interactive debugger.
- Enable some sort of class level MAC checking which can verify that no
changes were made to code before it is executed. 5) Prevent changes to compiled methods
Plus more that I'm sure will also be needed. If we can sign the image
and
VM and change the VM to check the signature before staring up and find a
way
to protect the live image then we will have gone a long way to having a
more
secure development platform.
I've mentioned this before and got absolutely no comment from anyone. (Maybe the email was too long to read?)
Some unstructured ideas from the top of my head: Securing a Smalltalk image is pretty difficult. The VM protects the system against a number of security holes such as buffer overflows etc. which would allow external attackers to compromise security. Protecting against internal attacks is much more difficult. If I were a computer security expert, I'd probably prefer an architecture where there is absolutely no possibility of adding new code to a running application. The Smalltalk image is *designed* to be the exact opposite of that :-) A truly secure VM/image combo would perhaps need to be done differently: The image should be split up into a read-only part containing classes and methods, and a writable part where the more mundane objects reside. Ideally, the read-only part would be protected using the hardware and OS mechanisms, so its integrity does not depend on the correctness of the VM and all its primitives. Of course, none of the development tools are supposed to be present in such an image, and even the hooks which they use should be carefully removed. There are some primitives (such as #become: and class-changing primitives) which a secure VM should either not implement or implement in a safer way. Checking the code integrity with checksums etc. is certainly a necessity. Linking to and depending on external code without checking its integrity as well is probably a no-no. Static linking is probably ok.
In any case, soothing the paranoia of security experts is going to be a difficult task. Once you know how many possibilities there are for tampering with software, you understand why...
Cheers, Hans-Martin
Hi Ron--
I would think that placing a certificate on the image file would be good enough "IF" we could prevent changes to the object structure and code in memory.
Doesn't that go out the window the first time you allocate and/or do a GC?
-C
Craig,
I would say that generally it is the responsibility of the developer (or company) to ensure that what is in the image and what can be created by the image is secure enough for the purpose that it is created. Obviously no company can protect itself from a government (especially ours) but a lot can be done to protect the system from well defined threats scenarios. Adding cryptography to the system communications, and protecting the image so that it performs only as the developer intends without change, plus using standard test to verify implementations of critical algorithms does make things better.
I would think that the best possible way to make a secure image is to build from the bottom up, with something like spoon, to add only the code that is necessary. To perform extensive automated code coverage tests. To harden the image and the VM to check code before it is executed against a release certificate. To add proper intrusion detection to disable the software if tampering is detected and to encrypt everything stored to disk including the image and the VM. That along with securing the communications should make the system good enough. (Using the proper algorithms like suite B and having observed NIST common criteria or having NIST certification of the software also helps).
What really gets me is that I've been programming in Smalltalk for 10 years now. I've written programs for a 2 billion dollar company. I know that Sprint uses Smalltalk for switching, and there are some very large insurance companies that use Smalltalk. It just can not be possible that Smalltalk is only appropriate for corporate intranet applications and can not be secured for the internet. Either I'm missing something or this is something that this group can add to the value of the language.
Ron Teitelbaum
From: Craig Latta Sent: Tuesday, August 01, 2006 12:17 AM
Hi Ron--
I would think that placing a certificate on the image file would be good enough "IF" we could prevent changes to the object structure and code in memory.
Doesn't that go out the window the first time you allocate and/ordo a GC?
-C
-- Craig Latta http://netjam.org/resume
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
On 31-Jul-06, at 1:50 PM, Hans-Martin Mosner wrote:
Some unstructured ideas from the top of my head: Securing a Smalltalk image is pretty difficult. The VM protects the system against a number of security holes such as buffer overflows etc. which would allow external attackers to compromise security.
Ah, I'll note that the squeak VM really hasn't been hardened against attack, it's much less paranoid than the VW VM. In many places we might pass a ByteArray and a length, where the length is calculated from the ByteArray in Smalltalk however nothing prevents someone from making that VM call with a bogus ByteArray and length and see if something interesting will happen. Of course if the host operating system API provides some interesting side effect ,when passing correctly constructed information from our viewpoint, the VM won't prevent attack.
Really *all* VM entry point would need to be looked at in a proper audit to avoid buffer overflow issues, even perhaps accidents which generally are fatal.
Yes yes, someday I promised making a list of the entry points, however workload seems to be stalling that event. Perhaps someone would be interested? That also needs to be done in order to create a set of SUnits so we can enable some degree of cross platform testing and help people who want to build a VM on a new platform.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hi--
John writes:
Yes yes, someday I promised making a list of the entry points, however workload seems to be stalling that event. Perhaps someone would be interested?
I also intend to do this eventually. I would do it now if it were paid.
-C
cryptography@lists.squeakfoundation.org
-
Bert Freudenberg -
Craig Latta -
Hans-Martin Mosner -
John M McIntosh -
Ron Teitelbaum -
tim Rowledge