In the XoJo framework, are variables confined to the original memory space assigned? Ex: If I create a string and store “Hello” into it, and later write “World” to that same string, is “World” written over the same memory blocks “Hello” was stored, or is “World” written first, and then “Hello” destroyed?
Further, does XoJo lock memory (or can it) from other OS applications? Can another application snoop XoJo’s memory space?
Usually the new string is created first and than the old memory is freed.
With enough permissions, other apps can look into all memory.
like apps written in any language. If you give me phyiscal access to a machine, I can grab anything I want out of memory.
Jeez guys, this isn’t really what i wanted to hear. Thinking out loud, Obviously if a host OS gets an infected, it can snoop on memory of any virtual machine being hosted. Also though, another virtual machine could be assigned memory that had previously been released by another virtual machine, as the host OS balances memory requests.
I was reading, and at least in Windows, there are two features, lock memory so it won’t be swapped virtually, and in .NET there is a specific variable type which is encrypted when stored in memory.
Since neither of these seem to be an option with XoJo, I’m beginning to think outside the box and isolate a given process to a Raspberry Pi box (since that is now an option in XoJo) and everything to and from that box is encrypted, and that box is the only place where un-encrypted data is processed.
it may be an option to lock memory.
Just you are the first to ask.
Just wondering : what is it you fear that would be accessed by another app snooping RAM ? Maybe if you care to elaborate, the danger you imagine may not be where you think it is.
A simple variable may not be that easy to snatch from memory. Especially if it is a computed property stored as encrypted on the fly in set, and decrypted on the fly in Get.
The most sought after by snoopers is not the program itself and its megabytes of mumbo jumbo, but rather the weak links that are input outputs like the screen, the keyboard, the network. By definition, even if you encrypt everything, you still need to present the UI in clear. Likewise, keyboard entries are by definition in human language.
Well, somewhere I had a function to clear bytes for a string, but I am not sure how helpful this is.
My function would overwrite the bytes for the string with zeros.
This particular application is for credit card data, but is could be any other data which should always remain encrypted when stored, and only decrypted for processing. This application creates a socket SHA2/TLS1.2 to a client requesting information, so from the customer to this app, it would be certificate encrypted. This app will decrypt it, process parts of the info, re-encrypt the data and forward to another process. A copy of the data would be encrypted to a SHA256 database until acknowledgements are received that the processes was completed, then the secure data is destroyed, and only a token will ever reference the transaction again.
But even if the application was scientific, say to compile medical statistics from hundreds of patients in a trial, you would decrypt the data (patient records), process it, and either re-encrypt it or discard it. A snooper or virus may have the opportunity to invade hundreds or thousands of personal and confidential information.
In light of more and more recent events, the need for keeping temporarily decrypted data for processing confidential will become more of a standard requirement.
Christian: I was thinking of that in those terms. Maybe instead of a string where I have little control, maybe a memoryblock where I can parse data within the block, then write random bytes over it when done. Again, though; behind the scenes what does XoJo do with:
Does it strictly read the string from the memory block byte by byte and send it TCP over the network. I’m guessing it might be transferred to a buffer first, encrypted and then sent over the network. In which case, I’m securing my MemoryBlock when done, but a discarded socket buffer still holds confidential information floating in available memory.
The thing is that software (generally) can’t prevent against a hardware bug, and it seems that hardware bugs are common - practical exploits against the RowHammer have been found: http://arstechnica.com/security/2016/10/using-rowhammer-bitflips-to-root-android-phones-is-now-a-thing/
Not to say that your concerns aren’t important, but that there is a bigger problem w.r.t. security that we all face.
another thing to remember also…
When you assign a value to a variable [S=‘Hello’], two thing happen,
a section of memory is set aside to store the 5 characters, and a POINTER is created so “S” knows where its payload is
Later if you assign S=“Orange” the same thing happens, but now the pointer is “different” (maybe, maybe not), but even so
any snoop might find “Hello” in memory, but wouldn’t know it had ever been assigned to “S”,
And a lot of compilers WILL use the same memory space if they can (especially if the new string is the same size as the old one), OR if the bytes following the original location are unused. And in the old days, every so often the system would pack up the variable heap, which would destroy old data automatically (not sure exactly how Xojo does all this)…
I think you biggest security threat is going to be the point of input and/or output to the real world.
Becuase if you have a program that is malicously snooping your memory, you have a virus, where a sniffer is a whole nother animal