AltME groups: search

Red is actually quite suitable for CGI, because the compiled executables 
are absolutely tiny, like they were in languages such as C when CGI 
was introduced. This means the performance will be quite good, not 
like the performance hit CGI suffers with heavy modern programming 
environments such as REBOL where the whole virtual machine needs 
to be started for every request. At the same time, you still have 
the advantages that made CGI popular: simplicity, robustness and 
security

It is probably not related, but you might try with secure none, but 
I does not seem to be problem of REBOL's security or licence missing 
...

The only cause I can think of is because the DLL produced by Red/System 
are not (yet) relocatable, they can be conflicting with other loaded 
DLLs (but shouldn't happen with a fresh REBOL session), or are triggering 
something in anti-virus or Windows security sub-systems.

Henrik, yes, Graham's link says that all the information is available. 
But then you're looking at complete reimplementations of a whole 
software suit that's extremely security critical

The new Windows Defenfer in Win8 is pretty much a relabeled Microsoft 
Security Essentials with a few more features. Haven't had a problem 
with MSE yet that wasn't resolvable.

Second thing I do: install Microsoft Security Essential (it's free) 
and forget about all common antivirus issues (slowness, instability, 
intrusive ads, false positives, ...).

Hopefully less buggy too. The rebcode dialect caused a lot of crashes 
and security holes, which is why it was removed. The new mechanism 
doesn't have that problem.

The advantage to rebcode isn't that it's fast, it's that its semantic 
model is similar to assembler. That makes it useful for a lot of 
interesting problems. Also, there might be times when you don't want 
to allow Red/System to be inlined - it's basically the same as unsafe 
code in C#, with the same security characteristics.

In Red, there might be an advantage to making a compiled rebcode 
equivalent (but without the stability and security bugs). Unlike 
REBOL (ignoring the debate), rebcode is inherently compilable. It 
wasn't designed to be interpreted the way REBOL was. It just had 
a fast interpreter implementation, which has been adapted to other 
dialects in R3.

Almost. It doesn't "replace" the word in all contexts, it registers 
another spelling for the word in the place where word symbols are 
stored, then when you refer to the word with either spelling it will 
point to the *same* word.
However, if you write code like this: alias 'print 'stampa

then that code, just by being loaded, creates two words in the user 
context with those two spellings. So when the ALIAS function links 
the two spellings then there is a conflict in the user context, where 
"stampa" refers to both the word 'stampa and is an alias for the 
word 'print and at runtime you can't really tell which word you mean. 
If the system resolves this conflict by resolving to the alias then 
you have overriden the original word, which makes ALIAS a security 
exploit. If it resolves to the original word then ALIAS simply doesn't 
work. Either way, the function needs to go away ASAP.

Right. As opposed to ALIAS, which can bring your system to a crashing 
halt, if you're lucky; if you're not lucky it will fail silently 
and stay a security hole.

Programming is a security hole. If you want to allow people to do 
safe programming, you have to make it safe by disallowing many things. 
That would obviously include ALIAS

Kaj: I share your security concerns about an appserver, but I don't 
think that other words datatypes can really be more secure. As long 
as you can force the LOADing of arbitrary input strings (without 
even evaluating the code), you could use it to make the symbol table 
blow up the memory.

It seems useful for dialects, and dialects are one of the main purposes 
of block parsing, and supposedly of Rebol. Beyond that it doesn't 
seem to be useful. It doesn't hurt to have it in there. Security 
was one of my initial concerns when Gabriele first proposed it, but 
R3's greater control of binding can be enough to deal with that issue 
so it's about as harmless as any method of implementing a dialect 
that allows code execution.

Yep, that might close a security hole for your TryRed I guess. You 
can also now build true closed-source software using Red. ;-)

There's a fundamental complaint among Android developers that you 
can't protect your apps against cracking, unlike on iOS, where Objective 
C apps are compiled. Petr showed how easy it is to decompile Android 
Java apps. With Red and the Java bridge, you can reach the same security 
on Android as native iOS apps. This could be an important marketing 
feature for Red

Saphirion's Host-kit has been updated:
-added PNG encoder
-added Core extension module for generic additional commands
-reworked compile/build process
-fixed security flaw in Encap
-fixed bug caused non-functional networking
-improved console output handling logic
-patched ENCODE to not crash on png
-updated LOAD-GUI with currentspahirion link
-recompiled r3.exe, r3core.exe, r3encap.exe and r3ogl.exe

Update on the web-page will be available on the weekend.

I have put my example script for CGI forms with validation and refilling 
previously filled fields online on the rebol.org site. http://www.rebol.org/view-script.r?script=cgi-form-val-example.r
Maybe somebody with more (CGI security) expertise can look at it 
and comment on safety issues please.

Just checked LinkedIn, he's working for some company called homeland 
security

There has to be something Rebol is doing beyond a simple language 
api to get level of security purported by Carl. 
What kind of pipes does it use?

There's nothing much special in REBOL regarding security

My misunderstanding then. I do not even know what 'pipes' are. I 
am posing the question on behalf of another. The question started 
based on the understanding from a conversation with Carl concerning 
the security benefits of AltMe and the once pending contract with 
the CIA.

but I'll probably be using modules as the basic construct for slim 
R3, instead of objects... in my model, it might not really matter, 
I manage access/biding to/from modules actually altering and expanding 
the module when it is being loaded.


the data being sent to slim isn't executed directly, the block is 
sent to a manager, which does some binding and security stuff first.

I can imagine that if you want to have a module somehow negitiate 
some passwords and don't want them to leak, or some other security 
issue, you might want to write the module to be isolated. Also, if 
Maxim wanted to port slim to R3, or someone wanted to port Qtask 
(I forgot what it's called now, sorry) or some other code written 
for Gabriele's PowerMezz modules to R3, they might want to use named, 
private isolated modules.

And, it does break through the APPLY security trick, which I might 
want to review some code about. I think that needs a ticket.
>> apply does [return/redo :add] [1 1] 1 1
== 2

Look here http://issue.cc/r3/1921before you do this. Make sure the 
security constraints mentioned there are taken into account.

I'd like to hear more about the security implications it has vs existing 
ways of affecting interpreted behaviour by self-modifying code.

The same bot  came back yesterday, via an anonymous proxy.

We are not alone -- this outfit is probing flaws in HTML forms on 
many (non-REBOL sites).

It would seem a reasonable security test on many websites to not 
allow sign-ups or feedback messages (etc) from anonymous proxies.

It was irrational.  Just security.

I found a critical bug: when rebol is configured to work as cgi engine 
with SELinux (Security Enhanced Linux), it generates a Segmentation 
Fault. I uses Fedora Core 3 with SELinux to secure the httpd daemon. 
For now, if you want to use rebol as a cgi engine, you must disable 
SELinux. See RAMBO Ticket #-376

older View used it for the security requesters. not sure if this 
is still the case with 1.3 or not.

I found a critical bug: when rebol is configured to work as cgi engine 
with SELinux (Security Enhanced Linux), it generates a Segmentation 
Fault. I uses Fedora Core 3 with SELinux to secure the httpd daemon. 
For now, if you want to use rebol as a cgi engine, you must disable 
SELinux. See RAMBO Ticket #-376

1) should be secure. decode-cgi should put only strings in the data, 
nothing executable. (i use a lot "should" when it comes to security 
and i did not double-check).
But why do you do that? simply 
 mold decode-cgi
should give the same.

Re. JS -- Netscape 4 used a technology called JS Style Sheets -- 
it was a horrific mess.  IE lets you evaluate JS within CSS -- it 
is a security risk, and of course does not work if JS is turned off. 
 Think of CSS as like an image format -- you don't evaluate PNGs, 
you just display them.

I use 'construct for security reason, but it's most understandable 
with 'make :

I've added an experiment with the Flash's security model http://box.lebeda.ws/~hmm/rswf/index.php?example=161
(there is added new tag so update your rswf dialect from the page) 
I'm not sure if it's working, but it should because it produces the 
same thing as this Macromedia's tool http://www.macromedia.com/support/flashplayer/downloads.html#lcu

Well Henrik, a basic rule of security is that attacks only get stronger, 
never weaker.
So just wait a while...... :-)

are there any security issues? infinite popups or anything left that 
might bring it out of control?

Seriously, I'd love a list of any security problems that you guys 
have encountered as you've used the plugin.

I haven't seen any, but then I've not tried to break security ..

If the chat client wipes your hard drive, consider it a security 
exploit!

Problem: the security certificate for IE has expired (about 2 months 
ago). We will need to renew it.

I need the plugin for an application that could potentially be used 
for a few thousand users in an open enterprise environment, but signed 
scripts and security are essential there.

Carl, one thing I thought about is how do you convince a user that 
the security in the plugin going through the webbrowser is trustworthy 
when the SSL icon in the browser window is not on? they might think 
that nasty stuff could be going on in the background. I think there 
needs to be some kind of indication that the script currently running 
is really secure.

The file shouldn't be that much bigger--not like going from Base 
to CommandView--so I'd say include everything needed for commercial 
use. Of course, this opens up security questions too (e.g. lib access).

Is this group more for bug fixes to the new plugin, or is it a place 
to make suggestions and discuss security issues?

security exploits .. private message josh.

Security Issues:

- We should to be able to restrict with the secure native what files 
and dlls the plugin can access.

- The default security of the RT-provided plugin (not encapped by 
a third-party) should prohibit any access to any local files or libraries 
at all, even in the same directory as the script, and prohibit access 
to third-party network addresses as well. Or at least ask.

- There should be some way to access the site's cookies from the 
plugin, because there shouldn't be any other way to store local data 
on the client computer's hard drive. Anything short of that will 
be a security hole.

- There should be no way to reduce the default security of the plugin 
through the use of plugin params.

- Any attempt to reduce access should prompt the user for permission, 
in terms a non-technical user can understand. This means rewriting 
the security dialogs to be more user-friendly.

- Any relaxation of these default security restrictions should require 
encapping the script.

- A user (or their lawyer) should to be able to (perhaps through 
RT) track down the author of any encapped script.

- An encapped script should count as a seperate plugin as far as 
the user is concerned, at least as far as permission-to-install is 
concerned.


Basically, the default security of the plugin should not allow scripts 
to do anything you wouldn't want your worst enemy to do on your computer. 
People will try to use this plugin for advertisements, for webbugs, 
for spyware, for every nasty thing that you aren't evil enough to 
think of. Avoiding that kind of thing should be the focus of the 
default security settings. Anything less will make the plugin unsafe 
to install.

Yes, and design the security dialog so that longer URLs are able 
to be fully shown,either by wrapping or scrolling.

We don't want the default plugin to be able to put even a single 
byte outside of the browser's purview without prompting the user 
first. Users have enough security problems to deal with without wondering 
if their banner ads are putting files on their hard drive. As it 
is I know many users who use AdBlock as a security measure - they 
don't care whether they see ads, but many of those ads contain nasty 
code and spyware installers.

That is the default security restriction of existing browser VMs.

The places a browser puts persistent data, and manages that data, 
are cookies and the temporary file cache. There are already security 
restrictions and management tools for those places. That existing 
persistent storage should be sufficient for REBOL scripts loaded 
by the regular plugin. Any other storage should be on the server, 
with the same server access restrictions as JavaScript. Anything 
more should be restricted to trusted sites.

if there is a breach in bank security it's all over the news immediately

Anonymous scripts should be able to read through the browser cache, 
at least for files from their own site, but should assume that those 
files won't necessarily persist beyond the browsing session. You 
don't want to give them a sandbox that doesn't have its space limited 
by the browser's existing facilities, for security and privacy reasons. 
You definitely don't want anonymous scripts to store more than cookies 
on your systems.


The guideline you should set for default behavior of anonymous scripts 
is to limit it to the activities that would be OK for deliberately 
malicious code to do. Assume that all anonymous code is out to get 
you until proven otherwise. This is a browser plugin you know - it 
will be used in banner ads.

Security settings often prevent users from installing applications 
.. so a browser app makes it easier for admins to distribute an application.

As for things like do-browser, it would be nice if the copy of REBOL 
called by the plugin could be passed some callbacks to which it would 
delegate some basic functionality like requesting a local file, proxy 
settings, do-browser, etc. This would allow the plugin to better 
integrate with the browser's existing behavior and security infrastructure.

By the way Josh, the security discussion we were having last night 
wasn't noise. Without the security restrictions discussed above noone 
would be able to safely install this plugin and allow it to run scripts 
from any but the most trusted sites. This is important.

thanks for the feedback. i apologize if i conveyed the idea that 
security discussions are noise. What I mean is that I don't have 
the bandwidth to sift through pages of discussion and build the plugin 
at the same time. So, for my sake, we need some kind of itemized 
system where Carl and I can tackle the issues one-by-one.

regarding security: so we need a list. i.e. change #1: disable xyz. 
change #2: make xyz a prompt that looks like this. etc.

Well, I can summarise the security proposals as discussed here and 
post them to your private message area if you prefer.

Sure, if you want. I'll edit the security entry I already put there.

I think that major versions should be installable side-by-side, and 
minor versions autoreplace so that security fixes can propagate.

A minor security "fix" can also break older code.

Security fixes should only break insecure code. Otherwise they are 
API modifications.

I like the API being able to wrap a one dll from each generation, 
and then update that dll for security fixes.

Interesting. OK, so we're leaning towards parallel side-by-side  
installs with automatic overwrite updates for security fixes?

I think a prompt is better, particulary for security updates.

Security updates are too important not to prompt for.

Anton, that won't work for webbugs. We want the security updates 
to be visible even when the applet isn't.

Especially when the applet isn't, since those kind of applets are 
more likely to be exploiting security bugs.

Here are the scenarios with resolutions in boolean logic as I see 
them right now:

 1. web_site_required_version not found on users computer -- download 
 required version

 2. web_site_required_version = version_on_computer && security_min_version 
 > version_on_computer -- popup, request download security update

 3. web_site_required_version = version_on_computer && security_min_version 
 <= version_on_computer && latest_version > version_on_computer -- 
 not sure

A legitimate webbug wouldn't be worried about showing a security 
update. An illegitimate one would be directly interested in hiding 
one since it may be depending on the security hole for exploit code.

Yes, we're assuming that the web site has no control over the security 
check, nor the security_min_version (that would come from RT)

So, we have a few different scenarios (using the numbering from above):

 1. In this case, the activex system in IE will force the download 
 of the (digitally signed) CAB found in the htm, which will come from 
 RT, and contain the Plugin version that works with this system. Nothing 
 new is required, this is how it works now.

 2. Here we need to enhance REBOL somehow to check for a security 
 update, prompt the user, and download an updater EXE. This is where 
 I think I will work next.

We could be conservative and not make unrequested non-security updates.

Volker, that is true. But the problem here is not COM interface/version 
compatibility. The problem here is: "Which REBOL binary to load?" 
Very simply put, if a web site relies upon plugin version 1.3.2, 
we must make sure that 1.3.2 -- or a later version backwards-compatible 
with 1.3.2 -- loads on their computer. At the same time, we need 
to deliver critical security updates and other non-breaking updates 
to users in a seamless manner.

Should we inform the user is a new update is avalaible?

I think this should be configurable for compatible updates. I guess 
some people might become nervous, if the plugin connects to the rebol.com 
site on every invocation. Even it is only looking for updates, well, 
you'll never know ...

On incompatible updates: The user should get a message along the 
lines: "You have installed the Rebol 1.3.4 plugin, this website needs 
the 3.0 plugin" of course only, if that is true.

I would ask for "download and install" for user convenience. Ver< 
few people would want to download and check the binary before installing 
it. Maybe you _could_ add a checkbox to "only download".

Well, I hate popups, but I hate not getting inmportant info even 
more ... so, I start downloadinf a webpage, while this page is loading, 
I open another tab, and work on this. Now I return to my first page 
later, and I find an embedded message "We're sorry, you first need 
to download the new plugin version" would make me go crazy :-) So 
I would like a popup in this case. 

Well, when there is a new security update, for maximum security, 
the plugin should stop to work until the user has answered, wether 
he wants to update, or go with the old plugin.

I agree with Maxim. Most people out there in the world don't have 
any reason to trust Rebol or Rebol Technology. It might be just another 
spyware company for all they know. Why would they (initially) want 
to allow an automatic software corridor into their computer ? It's 
an issue of trust. First let them try it out, then when they like 
what they see, allow them to enable more automatic security updates 
if they want.

So can we store a flag somewhere in the system? 
	automatic-security-updates = true / false;

3) Integration - the toughest part - first - old plug-in way of integration 
was not optimal. REBOL's code  of 'get-net-info is outdated and broken. 
First thing is to get proxy info automatically, if possible, but 
still allow it to be settable. Most corporate users do use proxy, 
without it, plug-in in non-existant product for corporate environment 
imo. Why to allow manual settings? Well, dunno how many companies 
do use it, but our company does :-( ..... "use script for proxy configuration" 
- and the script is JS code, which browser can interpret, but not 
rebol itself, so we need ability to set it manually


... or - second point and probably the main point from the architecture 
pov - do we allow what rebol allows? Do we allow our own networking, 
or will we allow only to tunnel via browser? One one hand, we would 
get https, on the other hand, if we limit it, we are not talking 
about rebol anymore, but sligthly different rebol based product. 
As for me, I am not able to see all the security related concerns, 
so I let it to others here ...

Henrik, with my suggested default network restrictions, that kind 
of security problem just won't happen without bringing up a security 
requestor that the user must agree to first.

With Java, the applet is only allowed to communicate with the server 
that served up the applet. We could make that same restriction by 
default in the REBOL plugin with SECURE, and then relax the restrictions 
at runtime with SECURE again. Of course, that will cause the security 
requester to pop up and the user would then know what they should 
know and agree to anyways before such behavior is allowed at all.

how about a simple flag, like a checkforupdates="true" attribute 
or something.  Every other operation, including the sort of actions 
that are necessary to install update is handled through normal security 
requestors.  ... yeah, like Brian said :)

I'm not sure that such information is possible through the DOM (which 
is where it would come from). wouldn't that be a security hole?

As far as web stuff goes, my customers want the "real life" apps. 
 Security needs range from completely disabled to something like 
java's, but being able to save files locally (save-as requestor).

Networking: as far as the browser can do the same, i would use browsers 
io. Or is it that much slower than rebols handler? Advantages are: 
proxy, cache. Maybe there are some extensions people like, about 
adds or blacklist or whatever? if such things exists they would be 
shared too. Its security , and a computer which knows my "no"s looks 
smarter.

... still we need imo ability to use networking/security model of 
browser, for those who need it (networking via browser). The question 
is with security - should plug-in allow default rebol security? That 
is the question ....

same here with excess security dialogs.  windows 2000

wouldn't that be a security hole?

Or take security/licensing......we could have the plugin DLL automatically 
download the correct version EXE (View/ViewPro/Command/etc.) based 
on the version the script requires (so the initial download could 
be quite small, with a "download as needed" architecture)

No.....not a security hole. Acrobat works that way.

I am working on a design doc for making the default security settings 
for the plugin more restrictive.

I know we talked about it a while ago, but those discussions are 
long gone from REBOL and from the web......I apologize, I should 
have archived them. Can you repost your thoughts on the default security 
model, in *concise* posts please? thank you!

Extra Security, some thoughts:
- 'secure for ips, eg: secure [net ask tcp://rebol.com allow]
- don't share sandbox-folders between hosts.
- if possible memory-restriction, hd, cpu?
- clipboard-restriction somehow?

- check for memory-access, specially disable struct! . IMO real hackers 
will figure out how to inject code by poke. 

- reblets can store executable code by naming the file *.exe. Does 
not run immediate, but script can open folder in explorer by browse, 
and one wrong click runs it. (or is windows smarter now? Maybe you 
could add an own extension always, and maybe store everything as 
64#{} ?

- Make sure untrusted reblets don't run invisible, can snoop clipboard, 
or at least users online-times. I guess creatives can find other 
uses.

- Maybe some kind of log about starts/stops, with urls? To have a 
little chance of tracking. Some kind of global console.
- Running out of thoughts for now.

A couple of quick thoughts:

[*] Don't allow reading/writing outside of a local sandbox......That 
includes not allowing access to URLs elsewhere on the web.  permitting 
wider local access and permitting wider web access should be separate 
security settings
[*] Disallow send by default

I would not limit rebol networking at all, I would add some security, 
yes, but not limitation ...

Volker. Jaime.  Clipboard access should probably raise a security 
request, like it does in (secured) browsers.   Maybe it should also 
be part of 'secure  ...

Looks like Volker covered the security issues I'd note.  About Rebol 
as a COM server process--I would think that would be the way to go. 
 Pretty sure that is how Acrobat runs, too.  Basically, the first 
time you run into a PDF on the web Acrobat32 starts, and handles 
all instances.

I agree, that some security is needed, but just want to say, not 
to give everything away just because there may be one bad guy

First thing what should be done is better security request window