Untrusted environment: Difference between revisions
Content deleted Content added
Added C section. |
Added Kotlin |
||
Line 45: | Line 45: | ||
With all that said, the language has seen limited use in contexts where code injection is a concern, so these mechanisms are rarely exercised (and somewhat [[J:System/Interpreter/Bugs#security_level_out_of_date|dated]]). |
With all that said, the language has seen limited use in contexts where code injection is a concern, so these mechanisms are rarely exercised (and somewhat [[J:System/Interpreter/Bugs#security_level_out_of_date|dated]]). |
||
=={{header|Kotlin}}== |
|||
Kotlin/JVM, which compiles to bytecode rather than to native code, has the same security features as other languages which target the Java Platform. |
|||
In particular the JVM verifies the bytecode to ensure that it cannot branch to invalid locations or address memory outside the bounds of an array. Pointer arithmetic is disallowed as are unchecked type casts. |
|||
The JVM also automatically allocates memory for new objects and deallocates memory for objects which are no longer needed using a garbage collector. Manual memory management is not supported. |
|||
It is possible to run untrusted bytecode within a 'sandbox' which prevents it from interfering with the underlying environment. However, programs can also be cryptographically signed by by a recognized authority and users can then allow such programs to be run within a trusted environment. |
|||
Of course, no system is perfect and a number of vulnerablities have been discovered in these mechanisms over the years and will doubtless continue to be discovered in the future given the ubiquity of the Java Platform and hence its attractiveness to hackers. |
|||
=={{header|PARI/GP}}== |
=={{header|PARI/GP}}== |