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).

... that makes it secure.

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.

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?

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.

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.

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.

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?

I have no idea what you are talking about.

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.
<…>

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?
...
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.

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.

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

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 that security is impossible --- this is not helpful in any way.

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.

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 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.

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.

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.

; 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.
    

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.