flat assembler
Message board for the users of flat assembler.

Index > Programming Language Design > Safety Forth

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
DimonSoft wrote:
Hugh-Aguilar wrote:
revolution wrote:
Java isn't secure. It runs code so it can't be secured. Same with JS, Python, etc.

Java was designed to be secure.

Java was marketed to be secure. Avoiding pointers gives some sort of potential reliability at the cost of more complex access to low-level features but has very little to do with security (except for the buffer overflow attacks, but whether they’re avoided completely is yet another topic to discuss).


This language is designed to be safe. Users can run programs without worrying that they are malware. Developers can distribute programs closed-source.

These registers are used:
RCX --- address of threaded code (1 MB)
RDI --- address of data memory

The threads are 16-bit, but are shifted left 4 bits to provide a 20-bit offset into the threaded-code memory (base is RCX).

All of the user's memory-access words use a 32-bit "pointer" (not an address). This is an offset from RDI. All of these words do bounds checking before accessing memory to ensure that they don't go out of bounds (presumably somewhat less than 4GB has been allotted for the system).

The user can't access threaded-code because the user doesn't know what value is in RCX --- the user can only access data relative to RDI. Also, the user doesn't know where the stacks are relative to RCX, so the attacker can't use a stack overflow or underflow to access threaded code. The only access to the threaded code memory is internal to the Forth system (done when it compiles code).

The result is that the user can only write code in Forth, and not in assembly-language, and can only access authorized data-memory. The only primitives available are the ones that I write in FASM that are built-in to the system.

DimonSoft said that Java doesn't use pointers, and this results in complexity. I do have pointers though, so programming in Safety Forth is similar to any other Forth that relies heavily on untyped pointers. My pointers are restricted to only access authorized memory --- that makes it secure.

_________________
When all else fails, write the source.
Post 04 Nov 2020, 19:54
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18071
Location: In your JS exploiting you and your system
revolution
Hugh-Aguilar wrote:
... that makes it secure.
It's a good start, but unfortunately there is more to security than eliminating pointers and memory leaks, and checking array bounds.

Security is more of a continuous process, not an end goal. If you want to see examples of how security fails even when the system is working perfectly then have a look at the JS thread.
Post 05 Nov 2020, 03:07
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
revolution wrote:
Hugh-Aguilar wrote:
... that makes it secure.
It's a good start, but unfortunately there is more to security than eliminating pointers and memory leaks, and checking array bounds.

Security is more of a continuous process, not an end goal. If you want to see examples of how security fails even when the system is working perfectly then have a look at the JS thread.

All of your talk about a "continuous process" seems like nonsense to me.
You are not defining "security," which is why you speak of a "continuous process."

I think that if I prevent the user from writing to unauthorized memory, then I am secure. I can allow the user to read and write to files, but only in the current directory. This will allow the user to access data files, but not to modify system files or anything else in other directories. It is not as difficult as you assume, to make a secure system.

Safety Forth programs are not going to be as fast as programs written directly in FASM. So it goes! Computers are very fast these days, and Menuet is a fast OS --- people won't mind if mundane programs are slow --- I'm not stopping anybody from writing a speed-critical program in FASM.

I skimmed over that thread that you referenced. You said:
revolution wrote:
Disable JS and flash. That gets rid of the nasty stuff

Disable third party cookies. Now you are 99% of the way there.

Clear your cookies each day or so. Now you are 99.9% done.

Forge your referer. 99.999% done.

Disable FRAMEs, IFRAMEs and external images. Now you are 99.9999% done.

If still worried then use proxies and make your browser ID string uniform. You're 100% done.

Did I miss something?

You definitely missed something! Safety Forth is not a browser nor a client language.
I have no intention of competing with JavaScript --- I don't know anything about how the internet works, or what a cookie is, etc. --- this has nothing to do with me.

Safety Forth is for the following purposes. This is in a rough order of importance to me, but this depends upon who the users (hopefully there will be users) are, and what they want to do.

1.) A host system for Forth cross-compilers for micro-controllers, typically 8-bit or 16-bit. These are mostly Harvard Architecture systems that can't write to code-memory at run-time, so they need a cross-compiler rather than a traditional interactive on-board Forth system. This is based on my MFX Forth cross-compiler for the MiniForth processor that I wrote when employed at Testra.

2.) A platform for CAM programs that generate gcode for CNC machines. Note that my number is a 64-bit fixed-point with unity = 2^32. This is about twice as fast as x87 double-precision IEEE-754 floats, but it has less precision and range --- should be adequate for CAM though.

3.) Mundane text-processing programs, most of which are data-format conversions. This is based on my STRING-STACK.4TH package that is currently written in ANS-Forth. This provides a lot of functions for pattern-matching and extraction of sub-strings.

4.) Processing statistics for "big data." My low-precision small-range numbers should be adequate for this, and speed is important when working with millions of data. This would be in competition with the R language.

5.) Programming games. These would be games similar to the 1980s classics such as Ms. Pacman and Centipede. Writing games such as these would be amusement for teenagers. These would not be modern first-person shooter games that I consider to be a negative contribution psychologically, and are beyond my ability to implement anyway.

My definition of "security" is that people can write programs such as these and distribute them closed-source, and users can download and run these programs without concern that they are malware. This would give Menuet an advantage over Linux and (especially) Windows --- security would become Menuet's purpose (Menuet doesn't have any purpose at this time, which is why it is not popular).

By "malware" I mean programs that do something evil.
Examples would be:
* searching your hard-drive for credit-card numbers
* taking control of your email program to send out spam using your email address
* tracking you, then providing this data about you to sales clowns who will spam you.
* etc.

_________________
When all else fails, write the source.
Post 05 Nov 2020, 07:56
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 937
Location: Belarus
DimonSoft
Hugh-Aguilar wrote:
I think that if I prevent the user from writing to unauthorized memory, then I am secure. I can allow the user to read and write to files, but only in the current directory. This will allow the user to access data files, but not to modify system files or anything else in other directories. It is not as difficult as you assume, to make a secure system.

Security is much more than that. All kinds of injections might have nothing to do with writing to unauthorized memory: just a logical mistake in the algorithm that makes it let user-specified data pass through and influence the program logic.

Closed-source is never really closed-source, especially in Java-like environments. Getting equivalent source code (maybe except originally used identifiers sometimes) is not that difficult. And is not a security boundary either.
Post 05 Nov 2020, 09:49
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
DimonSoft wrote:
Hugh-Aguilar wrote:
I think that if I prevent the user from writing to unauthorized memory, then I am secure. I can allow the user to read and write to files, but only in the current directory. This will allow the user to access data files, but not to modify system files or anything else in other directories. It is not as difficult as you assume, to make a secure system.

Security is much more than that. All kinds of injections might have nothing to do with writing to unauthorized memory: just a logical mistake in the algorithm that makes it let user-specified data pass through and influence the program logic.

What???
How is a "logical mistake" or a malicious attack going to let "user-specified data pass through and influence the program logic"???
The threaded code is a 1MB block of memory indexed off of RCX.
The data memory is a block of memory indexed off of RDI. If the data-memory is 1MB (the default) then the 32-bit offset (called a "pointer") is bounds-checked by @ and ! (fetch and store) before it is used to access memory. It can only access the 1MB of data memory --- it can not access the 1MB of threaded-code memory --- it can not access the machine-code primitives that were written in FASM and built in to the system.

You guys are just being defeatist. You are vaguely telling me that the user's program can easily access the threaded-code, but you are not telling me how this could happen. No matter what design I come up with, you are telling me that it is flawed and worthless, and "security is a continuous process," meaning that I can continue to develop enhanced designs and you will tell me that they are flawed and worthless too --- continuous failure!

I don't think that security is impossible as you say, or even difficult.
I think that it is possible to design the system so that programs can be distributed to the public and the user can run them without fear that the programs are doing anything malicious such as searching the hard-disk for private data (credit-card numbers, passwords, etc.) or modifying system files or any other files unauthorized to be modified.

Security is possible. There are downsides:

1.) Performance for Safety Forth programs will not be as good as programs written in FASM. Safety Forth is an ITC (indirect-threaded-code) Forth, so it is not comparable in speed to machine-code. Performance should be adequate for most applications. I'm not stopping people from writing programs in FASM --- this will continue to be common for speed-critical applications --- these programs will not be secure though, so users may refuse to download and run the programs due to fear that they contain malware.

2.) Programs can't use code-libraries written in C etc.. This isn't an issue on Menuet because C isn't available. If some ambitious Menuet programmer wrote a code-library in FASM for Menuet, such as for a database or 3D graphics or numerical functions, etc., this can't be accessed from Safety Forth.

3.) Programs are written in Forth, and a lot of people hate Forth. It may be possible to solve this if someone more ambitious than I am were to write a Safety Pascal or whatever. It would be best if this was compatible with Safety Forth so the two languages could coexist and programs in each language could execute the other language's functions.

#2 above is the most serious problem. If there is a FASM code-library that a lot of people want to use, then I could (with the author's permission) integrate it into Safety Forth as a set of machine-code primitives. I'm the only person who can do this because I'm the only person who can build Safety Forth from FASM code --- the Safety Forth user can only write code in Forth, but is not allowed to write in assembly-language.

DimonSoft wrote:
Closed-source is never really closed-source, especially in Java-like environments. Getting equivalent source code (maybe except originally used identifiers sometimes) is not that difficult. And is not a security boundary either.

I never said that close-source is a security boundary. Everybody knows that close-source is not a security boundary.
This is similar to encryption. The algorithm has to be public so it can be analyzed, but it can still provide good security against encryption cracking of private messages.

Closed-source is just a barrier to prevent theft from people (mostly in Red China, but elsewhere as well) who reverse-engineer other people's proprietary code and then sell it as their own. I don't want my software to end up being sold on MicroSoft Store or distributed as part of Kolibri, but if thieves try hard enough they will eventually reverse-engineer it and call it their own. This is like putting a deadbolt on your door to prevent a meth-head with a big screwdriver from jimmying open the door to go in your house and steal your stuff. Locks can be picked, but anybody with this much skill presumably has a job and hence is not interested in breaking into your house to steal your stuff and pawn it for drug money.

My definition of security is that programs can be distributed closed-source and the user can be guaranteed that the programs are not malware.
I'm not saying that closed-source programs can't be stolen --- reverse-engineering continues to be possible --- Red China relies heavily on theft, and they routinely succeed at this --- I can't stop them.
.

_________________
When all else fails, write the source.
Post 05 Nov 2020, 16:36
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 937
Location: Belarus
DimonSoft
Security is not a property of a programming language, it’s a property of particular program implementations. That’s the reason. If your language supports string concatenation and database queries, SQL injections will be possible in spite of all your security measures, one can only talk about probabilities of introducing them due to the language properties.
Post 05 Nov 2020, 17:36
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18071
Location: In your JS exploiting you and your system
revolution
If security were so easy then using Java and JS would not have all the problems they have now. Plus Windows and Linux wouldn't have any exploits.

Or is it just that the people writing those projects just don't understand how their things work?
Post 05 Nov 2020, 22:30
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
DimonSoft wrote:
Security is not a property of a programming language, it’s a property of particular program implementations. That’s the reason. If your language supports string concatenation and database queries, SQL injections will be possible in spite of all your security measures, one can only talk about probabilities of introducing them due to the language properties.

What???
When you say that security is a property of "particular program implementations" you are assuming that I allow the programmer to use any code-library that he feels like using, that may be written in C or FASM or whatever. I do not. See downside #2 above. The Safety Forth user is only allowed to use code-libraries that are written in Safety Forth and/or are written in FASM by me and provided as a set of primitives.

Considering that I'm a Forth programmer, how likely do you think it is that I'm planning on providing support for SQL, or that I even know what SQL is?

As for string concatenation, I do have that.
I have STRING-STACK.4TH currently written in ANS-Forth. This provides a stack of strings with COW (copy on write). I have "unique" strings that are on the heap. I also have "derivative" strings that are pointers into unique strings or constant strings. The system internally converts derivatives into uniques only when necessary. The user writes his code as if every string were a unique, without concern for whether strings are unique or derivative internally. Also, if a string is consumed, then it is automatically freed from the heap if it is a unique, but nothing is done if it is a derivative. The user doesn't have to manually allocate and free strings from the heap, or even know if they are on the heap or are just pointers into other strings.
String concatenation always produces a unique result. Creating a unique may fail if there is not enough room in the heap for the new string. This fails gracefully with an informative error-message. This is rare because the heap is gigantic. I have no idea what strings have to do with security.

revolution wrote:
If security were so easy then using Java and JS would not have all the problems they have now. Plus Windows and Linux wouldn't have any exploits.

Or is it just that the people writing those projects just don't understand how their things work?

What???
JavaScript wasn't designed to be secure, so it isn't going to be secure.
Windows and Linux are operating systems, not languages, so that is irrelevant to a discussion of language design. Also, they weren't designed to be secure either.
I have no idea what you are talking about. What???

As for Java, it was designed to be secure, and it is secure afaik. Certainly, nobody had ever succeeded in "jail-breaking" an Android phone in the sense that they could run their own ARM Cortex code on it. Java is secure because it prevents the user's programs from accessing unauthorized memory. It also prevents the user from running non-Java software, such as code-libraries written in C or FASM etc. Java requires all code-libraries used by Java programs to be written in Java. Safety Forth should be secure for the same reasons --- it doesn't access unauthorized memory, and all code libraries are in Safety Forth.

If Ville wanted security on Menuet, he could just introduce Java. He seems to hate high-level languages though, so this isn't going to happen. Also, there is the money issue --- he would have to pay for a license to have Java on Menuet. He said Safety Forth will not be a part of Menuet because he will never include a high-level language with Menuet --- he is okay with Safety Forth being provided for Menuet but not as a part of Menuet that he has to support.

I don't think that security is impossible, as you guys seem to be saying. Security is not that complicated. There are downsides, such as a lack of performance and a lack of code-libraries, but a usable and secure language is possible.

AFAIK, security is possible. Safety Forth would be secure.
At this time, I am focusing on writing the 8051 assembler and putting Safety Forth on the back-burner. Partially this is because Safety Forth is a much bigger project than the assembler which is fairly small and straight-forward. Also, though, there are maybe 100,000 people in the world who are actively programming in 8051 assembly-language. The number of people who are actively programming for Menuet and/or are programming in Forth is less than 100 (maybe not even 20).

_________________
When all else fails, write the source.
Post 07 Nov 2020, 08:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18071
Location: In your JS exploiting you and your system
revolution
Hugh-Aguilar wrote:
I have no idea what you are talking about.
Stating something is secure by declaration won't magically make it secure. Security is hard. I gave examples of things that are trying to be secure, but aren't. Because even though the people behind them are clever and the language/code doesn't even have buffer overruns and other things that are obvious problems, that still isn't enough. If you read through the JS thread I linked above, not just the first page, then you can see examples where things are insecure even though the underlying language was being used correctly.

The fundamental problem is that code being allowed to run is not audited or checked. So some random black-hat can find some method to circumvent all the protections. This is what Meltdown and RowHammer did, they exploited a flaw in the system, the hardware, and used JS to leverage that. Indeed they didn't need JS to have any flaws in order for them to work. So I can see the same thing happen with Forth, or any other language. People just have to accept that unaudited code can be a problem regardless of the system or language it is using to run itself.

So saying something like "Use my language, it is secure, and no problems can ever happen" is not being fair to the reader and fails to acknowledge the real world outcomes.
Post 07 Nov 2020, 08:55
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1608
Furs
You know, security vulnerabilities are called that way for a reason. They are usually not design flaws, or at least weren't known to be flaws when the design was made.

By design, privilege escalation vulnerabilities should not exist. In reality, they do exist. Bugs are a thing.

Sometimes you can't even do anything about it because the bugs or exploits are in the hardware: see all the Spectre exploits that need firmware updates.
Post 07 Nov 2020, 18:01
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 937
Location: Belarus
DimonSoft
Hugh-Aguilar wrote:
What???
When you say that security is a property of "particular program implementations" you are assuming that I allow the programmer to use any code-library that he feels like using, that may be written in C or FASM or whatever. I do not. See downside #2 above. The Safety Forth user is only allowed to use code-libraries that are written in Safety Forth and/or are written in FASM by me and provided as a set of primitives.

Considering that I'm a Forth programmer, how likely do you think it is that I'm planning on providing support for SQL, or that I even know what SQL is?

As for string concatenation, I do have that.
<…>

Not to offend you, but do you even know what an SQL-injection is?

OK, you’re not going to support SQL-based stuff. What about file paths? What about other DSLs that are widely used these days? What about any string data exchange with the outer world? How are you going to prevent a program from building a string from unfiltered user input?

There’s a solution for SQL-injections, it’s called “prepared statements”. But SQL-injections are still a thing, ’cause prepared statements are a means to avoid vulnerabilities, not a mechanism to completely prevent them. No matter how “secure” prepared statements are, there’s always a possibility of a mistake: some query gets built in a dirty concatenation way, or happens to get read from somewhere and that somewhere gets controlled by an attacker due to a mistake in some other part of the code.

If your language allows a program to pass arbitrary string data somewhere and that string data tells that other side what it should do, writing a vulnerable program is a matter of time and finding the vulnerability is a matter of attacker’s luck and desire. The same is true for non-string data as well.

The point is that impact of a programming language on program security is only indirect: if a PL is badly designed it might increase the probability of security bugs, a good PL might help to avoid them but can’t really prevent. So, saying that a PL is made to be safe and secure is just plain marketing.
Post 07 Nov 2020, 21:21
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
DimonSoft wrote:

What about file paths?

I already told you that Safety Forth would only access the current directory. This prevents SF programs from accessing system files or any other files that it is not authorized to access.
The user should only run SF in a directory containing files that he wants the SF program to access.
If you are doing Forth cross-compilation for some micro-controller, you would have SF and the SF cross-compiler in a directory, along with all of your own source-code for the micro-controller to be used as input, and this directory is where the output (likely Intel-Hex files) will go.
Similarly, if you are doing CAM, SF is in a directory containing all of your input files, and this is where the output (gcode files) will go.

DimonSoft wrote:

What about other DSLs that are widely used these days?

DSL means "domain specific language."
If they are "widely used" then they aren't written in Safety Forth so they can't be run by SF.
I have said multiple times that SF only runs SF code. It does not run arbitrary code-libraries written in C or FASM or whatever. I'm getting tired of saying this over and over again. It seems obvious that, for the system to be secure, it has to prevent any outside code from being called.

If the user wants to write a DSL in SF, that is fine with me. Charles Moore wrote a BASIC interpreter in Forth. Later on my friend Ching of Taiwan upgraded this significantly --- he seems to like it, apparently because it allows him to enter equations with infix notation compatible with math textbooks (he is a nuclear physicist).
I'm not opposed to people writing interpreters for other languages in SF, although I'm not much interested in the subject myself as I prefer to just program in Forth.

DimonSoft wrote:

What about any string data exchange with the outer world? How are you going to prevent a program from building a string from unfiltered user input?
...
If your language allows a program to pass arbitrary string data somewhere and that string data tells that other side what it should do, writing a vulnerable program is a matter of time and finding the vulnerability is a matter of attacker’s luck and desire. The same is true for non-string data as well.

I don't think strings are a problem.
If you generate a gcode file then it is full of strings that get passed somewhere (the CNC machine) and tells the other side what it should do (machine a workpiece). So what? Computers wouldn't very useful if they didn't generate data, and most data is in the form of strings.
The use of strings for data doesn't make SF insecure.

_________________
When all else fails, write the source.
Post 08 Nov 2020, 02:34
View user's profile Send private message Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
revolution wrote:

Stating something is secure by declaration won't magically make it secure. Security is hard.

That is very insulting!
You are saying that I'm stupid and rely on magical thinking in regard to security. That is not really true.

revolution wrote:

I gave examples of things that are trying to be secure, but aren't. Because even though the people behind them are clever and the language/code doesn't even have buffer overruns and other things that are obvious problems, that still isn't enough. If you read through the JS thread I linked above, not just the first page, then you can see examples where things are insecure even though the underlying language was being used correctly.

JavaScript is irrelevant because JavaScript was not designed to be secure.

Java was designed to be secure.
If anybody can point to security flaws in Java, I would be interested in hearing about that --- this likely would be relevant to Safety Forth that is based on the same general ideas about security as Java.

I don't want to hear about JavaScript or any other irrelevant nonsense --- this is not helpful in any way.
I don't want to hear that security is impossible --- this is not helpful in any way.

revolution wrote:

The fundamental problem is that code being allowed to run is not audited or checked. So some random black-hat can find some method to circumvent all the protections. This is what Meltdown and RowHammer did, they exploited a flaw in the system, the hardware, and used JS to leverage that. Indeed they didn't need JS to have any flaws in order for them to work. So I can see the same thing happen with Forth, or any other language. People just have to accept that unaudited code can be a problem regardless of the system or language it is using to run itself.

Who will audit Safety Forth programs?
This seems like an exhortation to rely on MicroSoft S-Mode that bans all programs except those from the MicroSoft Store.
Most likely, all Java programs are banned in S-Mode because MicroSoft wants people to use .NET and to believe that Java is insecure --- this is all about marketing, with no technical basis whatsoever.

Furs wrote:

Sometimes you can't even do anything about [security vulnerabilities] because the bugs or exploits are in the hardware...

Actually, I can do something about vulnerabilities in the hardware --- ban programming in assembly-language or programming in an HLL that generates machine-code, for anybody who wants security.

Internally, I have RCX pointing to the 1MB block of threaded code, and RDI pointing to the 1MB block of data. All of the user's data access is with @ and ! (fetch and store) that use an offset from RDI with bounds-checking. The user can not access memory outside of the 1MB allotted for data, and the user can't execute machine-code other than my primitives written in FASM and built in to the system.
How is this not secure?

_________________
When all else fails, write the source.
Post 08 Nov 2020, 04:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18071
Location: In your JS exploiting you and your system
revolution
You declare that SecureForth will be secure, but discuss only a small subset of actual security problems that happen. You haven't addressed anything for Meltdown, RowHammer or Spectre. Plus whatever future problems show up.

Banning assembly or HLL won't make your language secure. Things can be insecure, not because of the language, but things outside of the language. Things that you have no control over. And the language (any language) is used as leverage to exploit such problems. There is literally nothing that you can do, aside from deleting everything, that will make your code bypass all possible security problems.
Post 08 Nov 2020, 05:02
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 937
Location: Belarus
DimonSoft
Hugh-Aguilar wrote:
Java was designed to be secure.
If anybody can point to security flaws in Java, I would be interested in hearing about that --- this likely would be relevant to Safety Forth that is based on the same general ideas about security as Java.

I’m really sorry to break your imaginary world, but here’s what I instantly get with plain keyword search: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java

Hugh-Aguilar wrote:
I don't want to hear that security is impossible --- this is not helpful in any way.

Security is possible. Your translator can be secure. But you can’t guarantee that programs written for it are secure. Unless you limit you language to juggling data and simple arithmetics without any input and output. Even then I wouldn’t be sure if it is secure but at least security would really depend on the sandbox implementation.
Post 08 Nov 2020, 10:12
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
revolution wrote:
You declare that SecureForth will be secure, but discuss only a small subset of actual security problems that happen. You haven't addressed anything for Meltdown, RowHammer or Spectre. Plus whatever future problems show up.

Banning assembly or HLL won't make your language secure. Things can be insecure, not because of the language, but things outside of the language. Things that you have no control over. And the language (any language) is used as leverage to exploit such problems. There is literally nothing that you can do, aside from deleting everything, that will make your code bypass all possible security problems.

I find it annoying when nattering nabobs of negativity tell me: "There is literally nothing that you can do..."

I changed my tagline to say: "When all else fails, write the source."
This was done to mock Revolution. Laughing
I really despise maintenance programmers!
I wrote MFX at Testra, but Tom Hart told me that I wouldn't get a raise and that he can hire anybody to replace me. Now he says: "Hugh had no part in [MFX]. The design was done long before Hugh showed up." Tom Hart is a liar!
In 25 years, Testra has never found a maintenance programmer who could learn the MFX assembly-language or understand how the assembler works. This is because MFX is very complicated.
Most programs aren't very complicated though, and maintenance programmers can figure out how they work. This doesn't mean that the maintenance programmer is equal to the original programmer though.
The maintenance programmer is a parasite --- the original programmer did all of the work --- even if it was straightforward work, the original programmer still deserves credit for writing the program.

There are two purposes for Safety Forth:
1.) Programmers can release their programs closed-source to prevent maintenance programmers from reading their source and then pretending to be the author.
2.) Users can download these closed-source programs and feel confident that they are not malware --- the programs won't access memory outside of their allotted memory --- the programs won't access files outside of the current directory.

DimonSoft wrote:
Hugh-Aguilar wrote:
Java was designed to be secure.
If anybody can point to security flaws in Java, I would be interested in hearing about that --- this likely would be relevant to Safety Forth that is based on the same general ideas about security as Java.

I’m really sorry to break your imaginary world, but here’s what I instantly get with plain keyword search: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java

Hugh-Aguilar wrote:
I don't want to hear that security is impossible --- this is not helpful in any way.

Security is possible. Your translator can be secure. But you can’t guarantee that programs written for it are secure. Unless you limit you language to juggling data and simple arithmetics without any input and output. Even then I wouldn’t be sure if it is secure but at least security would really depend on the sandbox implementation.

I'm not supporting internet access. The only I/O I support is to files in the current directory. Also, the keyboard and screen are supported, obviously.

You are another nattering nabob of negativity, telling me that I can only write programs:: "without any input and output."

I upgraded my design. I decided that I need to do bounds-checking on the data-stack pointer to prevent a black-hat from purposefully overflowing or underflowing the data-stack to access outside memory. The good news though, is that this bounds-checking parallelizes with the NEXT code so it doesn't take any time.
More good news is that I have freed up RCX because I now have my threaded code relative to the base pointer (threaded code is in the negative side and data is in the positive side). I have more efficient use of registers now. Smile

_________________
When all else fails, write the source.
Post 14 Nov 2020, 20:15
View user's profile Send private message Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
Hugh-Aguilar wrote:

I wrote MFX at Testra, but Tom Hart told me that I wouldn't get a raise and that he can hire anybody to replace me. Now he says: "Hugh had no part in [MFX]. The design was done long before Hugh showed up." Tom Hart is a liar!
In 25 years, Testra has never found a maintenance programmer who could learn the MFX assembly-language or understand how the assembler works. This is because MFX is very complicated.
Most programs aren't very complicated though, and maintenance programmers can figure out how they work. This doesn't mean that the maintenance programmer is equal to the original programmer though.
The maintenance programmer is a parasite --- the original programmer did all of the work --- even if it was straightforward work, the original programmer still deserves credit for writing the program.

Tomasz Gryszar is from Poland --- perhaps he can tell us about Filipiak.

_________________
When all else fails, write the source.
Post 14 Nov 2020, 20:25
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18071
Location: In your JS exploiting you and your system
revolution
So if we ignore your personal attacks above, I still see nothing that addresses Meltdown, or RowHammer, or Spectre. What have you done to address those issues?

If you don't address those issues at least then running arbitrary code can't be secure.
Post 14 Nov 2020, 22:05
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
DimonSoft wrote:

Security is possible. Your translator can be secure. But you can’t guarantee that programs written for it are secure. Unless you limit you language to juggling data and simple arithmetics without any input and output. Even then I wouldn’t be sure if it is secure but at least security would really depend on the sandbox implementation.

I said earlier that I would only allow access to files in the current directory.
I will revise this to say that I will allow access to files in the current directory and all subdirectories. For example, for a CAM program, the user would have subdirectories for
different machines (mill, lathe, laser-cutter, etc.). He would have subdirectories in each for each machine-part he is making. All told, there may be hundreds of files.
This is still secure because the user created the directory and all of the subdirectories underneath, so those files are his.

I'm expecting CAM to be the "killer app" for Safety Forth. This is a subject I know something about and am interested in.

revolution wrote:

So if we ignore your personal attacks above, I still see nothing that addresses Meltdown, or RowHammer, or Spectre. What have you done to address those issues?

If you don't address those issues at least then running arbitrary code can't be secure.

Apparently Revolution the maintenance programmer who reads source, also reads magazine articles. This is where he learns about Meltdown, Spectre and RowHammer --- now he beats me up with his awesome knowledge. Laughing

I don't think that Revolution knows what a virtual machine (VM) is. Safety Forth does not generate machine-code! The user's code is compiled into "threaded code" for a VM. All of the primitives, that are machine-code, are built-in to the system and written by me in FASM.

The programs are distributed closed-source as binary overlays of the threaded-code memory. These apps would be encrypted so a black-hat can't generate his own using an outside program and then have it loaded into Safety Forth and executed.

This is my register map now:
Code:
; These are the register dedications:
;               rax     ; general purpose
;               rbx     ; top value of single-wide data stack
;               ecx     ; returns-stack pointer                         ; an offset
;               rdx     ; general purpose
;               rsi     ; interpretive pointer                          ; a 64-bit address
;               edi     ; the locals frame in the return-stack          ; an offset
;               rbp     ; the address of the zero location in memory    ; a 64-bit address
;               rsp     ; the single-wide data stack pointer            ; a 64-bit address
;               r8      ; general purpose
ss      equ     r9d     ; the string-stack pointer                      ; an offset
ptr     equ     r10d    ; the PTR user-register                         ; an offset
cnt     equ     r11d    ; the CNT user-register                         ; a 32-bit count
ds      equ     r12d    ; the double-wide data stack pointer            ; an offset
rtos    equ     r13     ; the top value of the data-stack (only for >R data)
lo      equ     r14     ; low word of top value of double-wide data stack
hi      equ     r15     ; high word of top value of double-wide data stack

; The DF flag is always clear (0) so LODSW etc. advance forward.
; RSI is the interpretive pointer for threaded code. 
; The xt values are 16-bit. They get shifted left by 4 then negated for an offset into threaded memory.
; All colon words start on paragraph (16 byte) boundaries. 

; Theoretically, then negation of the offset into code memory could be eliminated. 
; Code would be in the positive side and data in the negative side.
; It would be very confusing for the user to have negative pointers to data memory! 
; The NEG RAX in NEXT2 (shown later) isn't costly enough to warrant getting rid of it.

2*MB-1  equ     offset  ; a mask for the offset into data memory
; Data memory is currently set at 2 MB. It can be any power of two.

; Code memory is currently set at 1 MB. It can be any power of two >= 64KB.
; The threads are only 2 bytes, so code is pretty small. One MB should be more than adequate.
; Making the threads small helps to reduce cache thrashing while interpreting.
    


RBP is the pointer into our memory. There is 1 MB of threaded-code in the negative side and 2 MB of data in the positive side. The user only has access to the positive side. The pointers are 32-bit (the integer part of a number) but they get AND'd by OFFSET before being used, so only the 2 MB of data memory is accessible.

If anybody wants to write their own compiler, such as Safety Pascal or whatever, it would be useful if the same register map was used, along with the same threading scheme. This is my NEXT code:
Code:
macro check_overflow    ; bounds-check RSP --- done by any primitive that pushes data
{
        cmp rsp, stack_lower_limit
        jbe single_overflow
}
        
macro check_underflow   ; bounds-check RSP --- done by any primitive that pops data
{
        cmp rsp, stack_upper_limit
        jae single_underflow
}

; A thread is a 16-bit unsigned value. This gets shifted left 4 bits to be a 20-bit value.
; The shifted thread is negated and added to RBP to obtain the pointer to the function.
; An XT (such as EXECUTE uses) is 64-bit. The upper half is the pointer (negative) to the function.
; The lower half is the frame pointer for colon words, or zero for quotations.

macro next1             ; set EAX= shifted thread, advance RSI 
{
        lodsw                   ; AX= 16-bit thread
        shl eax, 4              ; EAX= 20-bit shifted thread, accessing 1 MB of code memory.
}

macro next2             ; needs EAX = shifted thread, sets RAX= address of function
{
        neg rax                 ; RAX= negative offset into code memory
        lea rax, [rbp+rax]      ; RAX= address of function (RBP points to the zero of code memory)
}

macro next3             ; needs RAX = address of function, jumps through the cfa
{
        jmp qword [rax]
}

macro next23            ; needs NEXT1 already done
{
        next2
        next3
}

macro next              ; used for primitives that leave the data stack at the same level
{
        next1
        next2
        next3
}

producer_next:          ; used for primitives that push elements to the data stack
        next1
        check_overflow          ; should parallelize with SHL RAX, 4 and NEG RAX so it is free
        next23

consumer_next:          ; used for primitives that pop elements from the data stack
        next1
        check_underflow         ; should parallelize with SHL RAX, 4 and NEG RAX so it is free
        next23

; Producers are words such as LIT that push data onto the data stack.
; Consumers are words such as + that pop data from the data stack.
; Words that neither produce nor consume, such as @ etc., can use NEXT without bounds checking.
; It is possible to do the NEXT1 NEXT2 and NEXT3 explicitly and put code between them.
; Just make sure that the code after NEXT1 doesn't modify RAX or RSI.
; CHECK_OVERFLOW only needs to be done for primitives that push data.
; CHECK_UNDERFLOW only needs to be done for primitives that pop data.
; Thoroughly checking for underflow and overflow prevents a black-hat from purposely
; underflowing or overflowing the data-stack to modify unauthorized memory.

; Every function has a 64-bit cfa in front, which is the address of the machine-code.
; Quotations don't have this cfa though, because it would always be DOCOLON anyway.
; The DOCOLON code is bundled into .EXECUTE_QUOTATION for improved efficiency.
    

This code isn't tested. I haven't yet got FASMW to work on Windows. I still have that S-Mode problem. I really have a limited amount of time to work on this project --- I'm putting in a lot of hours at my regular job --- I mostly just sleep in my free time.

There seems to be zero interest in Safety Forth. All I've gotten so far are the nattering nabobs of negativity who tell me that a safe system is impossible. This isn't true though --- it should be possible to design Safety Forth in such a way that it can't be used to write malware, and the programs can be released closed-source to prevent maintenance programmers from reading the source.
I won't bother posting any more about it if there is no interest.

_________________
When all else fails, write the source.
Post 16 Nov 2020, 01:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18071
Location: In your JS exploiting you and your system
revolution
And still you haven't addressed Meltdown, Rowhammer or Spectre. No amount of VMs, or it's-not-asm-code defeats those attacks. You need something much different for those.

Let's start simply. Show how you detect and counteract Rowhammer. Once you have that one solved then we can moved on to the next one.
Post 16 Nov 2020, 03:00
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.