Re: making firefox less insecure

[Gareth Osler]

Check out Fortress Linux, possibly using a version of xombrero,
not sure https://www.fortresslinux.org/

Myself I was planning to use a separate login for web browser,
streaming audio visual, etc, alongside an offline desktop for work
on documents but with ports open to read and send e-mail, access
a ssh account, etc. - a 'disaster rocovery' approach; plan on
minimizing the damage and recovering as quickly as possible following
a breach.

I guess I should also make more use of profiles to separate misc.
surfing from web accounts.

In the past code injection has essentially rendered unencryypted
Internet useless for myself. Encryption wise OpenVPN has not proved
reliable, nor L2TP for some odd reason, though things may have
changed with the recent SSL fixes (I'll give them another go at
some point).  However ssh running as a socks server seems to work
fine, firefox will also resolve DNS calls over the socks connection
(privoxy and polipo can be used to set up a socks forwarding http
proxy for other applications and which usually will resolve DNS
over the proxy also).

Having used xombrero for a while I tend to configure firefox as
similar as possible.  NoScript usually only allowing scripts called
from the web page itself (i.e., click 'allow' once and no more),
AdBlock with all filtering options enabled, disable disk and memory
cache, DNS and page prefetch, spoof the browser ID, I don't use
this addon bit it gives a good idea of the setting that can be used
to render firefox anonymous
https://github.com/dillbyrne/random-agent-spoofer/ HTTPS Everywhere
https://www.eff.org/https-everywhere

Type about:support into the address bar to get an overview of what
setting are set, etc.  also eff.org's https://panopticlick.eff.org/

None of the above is any use unless the install is relatively
untainted security wise, I run a very tight firewall also (but not
yet got round to setting up the monitoring end of things yet), this
I'm sure has helped in the past.  I have learnt DNS servers are
not reliable also - prefereably encrypt DNS, if not then use a
server that advertises enhanced security as a feature.

The net result, I only experience data injection occasionally
nowadays (though obviously I cannot be 100% sure), more of a problem
seems to confidentiality.

As to the future, EMF issue, how secure are FreeBSD jails?, DNSSEC?,
port the lot to Fedora, review of current authentication options
in addition to password strategy -
https://www.yubico.com/2014/11/neo-supports-u2f-otp-key-time/ looks
interesting, etc.

Re: making firefox less insecure

[Ted Unangst]

On Thu, Nov 27, 2014 at 01:07, Jonathan Thornburg wrote:
> Summary
> ---
> As described in another thread
> (),
> I'm trying to run firefox as a non-privileged user _firefox, talking
> to my X server (no Xephyr yet) via an ssh tunnel.  But I've discovered
> a serious flaw in this scheme: cut-n-paste is completely broken.  In
> fact, it looks like cut-n-paste from any X client with a diferent
> uid/gid than the X server is broken. :(
> 
> My basic question is, is there any way to fix this?

That is "by design". Secure X sessions do not permit access. If you
want to grant full access to the X session, use ssh -Y for an insecure
connection.

The fact that basically every X client application crashes in this
case is somewhat less by design, but as a practicaly matter, nothing
handles these errors appropriately.

Re: making firefox less insecure

[Martin Brandenburg]

Jonathan Thornburg  wrote:

> Summary
> ---
> As described in another thread
> (),
> I'm trying to run firefox as a non-privileged user _firefox, talking
> to my X server (no Xephyr yet) via an ssh tunnel.  But I've discovered
> a serious flaw in this scheme: cut-n-paste is completely broken.  In
> fact, it looks like cut-n-paste from any X client with a diferent
> uid/gid than the X server is broken. :(
> 
> My basic question is, is there any way to fix this?

This is the point, of course, that the client cannot communicate with
the host X server. It's not just from a different uid. I think the
easiest solution would be to write a script which you can run in a host
xterm "ffpaste ..." which makes ... the clipboard in the Xephyr window.
Of course you could probably also write a script to sync the clipboard
automatically (and in fact this is the top result for a Google search
"Xephyr copy paste"), but perhaps this would default the purpose of
running Firefox in a different X server.

Oh I'm sorry, I read that wrong. If you use Xephyr the clients cannot
communicate clipboards (of course they can communicate otherwise if they
are running as the same user). The above is right for a client in
Xephyr.

I can, however, paste into an X client running on another machine in the
same X server. I don't have a local SSH server and didn't try that, but
I fail to see why that shouldn't work since it goes over the network 
irregardless of what user the process runs as. But that X client can
talk to all the other X clients on this server and that defeats the
whole point of all this.

A note however: it would be very nice if Firefox would fork, chroot, and
drop privileges on the renderer. Perhaps I shouldn't say this without
having Mozilla's opinion on such a scheme, but Mozilla seems more
interested in shiny redesigns. As Theo said to your inquiry about a
secure image viewer, such behavior is rare outside OpenBSD.

> 
> 
> 
> Details:
> ---
> 
> Lenovo Thinkpad T60, 3GB RAM + 6GB swap.  Fresh install of OpenBSD 5.6
> from the CD, updated to -stable as of 2014-11-19.  My usual login is
> in login class staff, for which I've edited /etc/login.conf to set the
> memoryuse, datasize, and stacksize limits (all both -cur and -max) to
> 'infinity', so there should be enough memory for firefox to run ok.
> 
> I use twm(1) as my window manager.  firefox is the 5.6 package, but
> I've renamed the binary:
> 
> # cd /usr/local/bin; mv firefox firefox.bin
> 
> I used adduser(8) to create a new unpriviliged user _firefox,
> group _firefox, no other group memberships, login class staff.
> I've set up ssh authentication so I can ssh to _firefox.
> 
> Now, in an xterm, call it xterm #1:
> % ssh -X -i $HOME/.ssh/firefox_id_rsa _firefox@localhost
> 
> This gives me a shell (in that same xterm #1) running as uid/gid
> _firefox, with ssh proxying and tunneling X back to my X server.
> (I'm not using Xephyr(1) at this point.)
> 
> Now, in the _firefox shell,
> 
> $ firefox.bin &
> 
> I get a a couple of warning messages that the ssh proxy/tunnel is
> lacking some X protocol extensions
> 
> Xlib:  extension "RANDR" missing on display "localhost:10.0".
> Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".
> 
> but then firefox starts and runs fine.
> 
> Now suppose I try to cut-n-paste some text from the firefox window to
> (say) a vi (in insert mode) which is running in some other xterm window
> (call this one xterm #2).  [For twm, 'cut-n-paste' means double- or
> triple-left-click to select, then middle-click to paste.]  This goes
> badly awry:
> * the cut appears to work normally (text is highlighted)
> * the paste appears to be a no-op, ... but
> * a few seconds later, the target xterm window (#2) disappears (and
>   the vi and xterm processes are gone)
> 
> 
> 
> To see if this is a firefox issue, or a more generic problem with
> cut-n-paste between X clients running with different uid/gid, I tried
> starting an xterm instead of a firefox process.  That is, from the
> _firefox shell, I typed
> 
> $ xterm &
> 
> and in the newly-started xterm (call it xterm #3) typed a few commands
> to put some text on the screen
> 
> $ echo hello world
> hello world
> $ banner hello
> 
>  ##  ##  #   #
>  ##  #   #   #   ##
>  ##  #   #   #   ##
>  ##  #   #   #   ##
>  ##  #   #   #   ##
>  ##  ##  ##  ##   
> 
> $
> 
> then I tried to cut-n-paste the banner 'hello' text from xterm #3
> into somewhere else.
> 
> The result was that the cut operation killed the xterm #3 window, with
> the following X error message displayed back in the _firefox shell
> running in xterm #1:
> 
> $ xterm &
> [1] 25801
> $ xterm: warning, error event received:
> X Error of failed request:  BadAccess (attempt to access private resource 
> denied)
>   Major opcode of failed request: 

Re: making firefox less insecure

[Jonathan Thornburg]

In message ,
I wrote
> [For twm, 'cut-n-paste' means double- or
> triple-left-click to select, then middle-click to paste.]

Oops, that's wrong -- there are also other ways to select in twm.
The distinction between different ways of selecting is irrelevant here,
so what I should have written was

  [For twm, 'cut-n-paste' means select the text to be cut
  in the source window, then middle-click in the destination
  window to paste.]

Sorry for the confusion,

-- 
-- Jonathan Thornburg 
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
at any given moment.  How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork.  It was even conceivable
that they watched everybody all the time."  -- George Orwell, "1984"

Re: making firefox less insecure

[Jonathan Thornburg]

Summary
---
As described in another thread
(),
I'm trying to run firefox as a non-privileged user _firefox, talking
to my X server (no Xephyr yet) via an ssh tunnel.  But I've discovered
a serious flaw in this scheme: cut-n-paste is completely broken.  In
fact, it looks like cut-n-paste from any X client with a diferent
uid/gid than the X server is broken. :(

My basic question is, is there any way to fix this?



Details:
---

Lenovo Thinkpad T60, 3GB RAM + 6GB swap.  Fresh install of OpenBSD 5.6
from the CD, updated to -stable as of 2014-11-19.  My usual login is
in login class staff, for which I've edited /etc/login.conf to set the
memoryuse, datasize, and stacksize limits (all both -cur and -max) to
'infinity', so there should be enough memory for firefox to run ok.

I use twm(1) as my window manager.  firefox is the 5.6 package, but
I've renamed the binary:

# cd /usr/local/bin; mv firefox firefox.bin

I used adduser(8) to create a new unpriviliged user _firefox,
group _firefox, no other group memberships, login class staff.
I've set up ssh authentication so I can ssh to _firefox.

Now, in an xterm, call it xterm #1:
% ssh -X -i $HOME/.ssh/firefox_id_rsa _firefox@localhost

This gives me a shell (in that same xterm #1) running as uid/gid
_firefox, with ssh proxying and tunneling X back to my X server.
(I'm not using Xephyr(1) at this point.)

Now, in the _firefox shell,

$ firefox.bin &

I get a a couple of warning messages that the ssh proxy/tunnel is
lacking some X protocol extensions

Xlib:  extension "RANDR" missing on display "localhost:10.0".
Xlib:  extension "MIT-SHM" missing on display "localhost:10.0".

but then firefox starts and runs fine.

Now suppose I try to cut-n-paste some text from the firefox window to
(say) a vi (in insert mode) which is running in some other xterm window
(call this one xterm #2).  [For twm, 'cut-n-paste' means double- or
triple-left-click to select, then middle-click to paste.]  This goes
badly awry:
* the cut appears to work normally (text is highlighted)
* the paste appears to be a no-op, ... but
* a few seconds later, the target xterm window (#2) disappears (and
  the vi and xterm processes are gone)



To see if this is a firefox issue, or a more generic problem with
cut-n-paste between X clients running with different uid/gid, I tried
starting an xterm instead of a firefox process.  That is, from the
_firefox shell, I typed

$ xterm &

and in the newly-started xterm (call it xterm #3) typed a few commands
to put some text on the screen

$ echo hello world
hello world
$ banner hello

 ##  ##  #   #
 ##  #   #   #   ##
 ##  #   #   #   ##
 ##  #   #   #   ##
 ##  #   #   #   ##
 ##  ##  ##  ##   

$

then I tried to cut-n-paste the banner 'hello' text from xterm #3
into somewhere else.

The result was that the cut operation killed the xterm #3 window, with
the following X error message displayed back in the _firefox shell
running in xterm #1:

$ xterm &
[1] 25801
$ xterm: warning, error event received:
X Error of failed request:  BadAccess (attempt to access private resource 
denied)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Serial number of failed request:  599
  Current serial number in output stream:  600

[1] + Done (83)xterm 
$

(Interestingly, I had no problem cut-n-pasting that error text from
xterm #1 into a vi (in insert mode) over in still another xterm window.



What I conclude from all of this is that (apparently) my window manager
and/or X server have noticed that {firefox, xterm #3} are running as
uid/gid _firefox/_firefox, while my {window manager, X server} have my
usual (different) uid/gid, so the cut-n-paste attempt (indeed, the cut
itself, judging by the xterm error message) is blocked.

So... questions:
* is this indeed what's going on?
* it's been a long time since I tried cut-n-paste from a 'remote'
  window; is this what usually happens [I'll try some tests...]?
* what piece of software is enforcing this security policy?
  (once I find that out, then I can investigate if/how the policy
  might be configured to be more suitable to my needs)
* given my underlying goal of trying to exploit-mitigate firefox
  (),
  what other options are there for handling cut-n-paste?
  (Maybe xcutsel(1) and/or xclipboard(1) would be useful here?)

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" 

   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
at any given moment.  How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork.  It was even conceivable
that they watched everybody all the time."  -- George Orwell, "1984"

Re: making firefox less insecure

[Jiri B]

On Sun, Nov 23, 2014 at 02:41:10PM -0500, Jonathan Thornburg wrote:
> > I can see several possible forms of exploit-mitigation:
> > (a) use the noscript firefox extension to block javascript
> > (b) use capsicum to sandbox forefox and any plugin processes
> > (c) run firefox in a chroot jail
> > (d) have firefox talk to an Xephyr(1) instance
> > so it's semi-isolated from the main X server
> > (e) maybe have firefox go through an ssh tunnel to localhost
> > (f) run firefox as an unpriviliged user _firefox, group _firefox, and
> > use Unix file permissions to deny that user access to $HOME/

Well, other way could to use Qubes OS as "hypervisor" (yeah x86
virtualization) and run OpenBSD as VMs. Although OpenBSD is not para-
virtualized for Xen but Qubes OS supports Windows and they just need
to support vmchannel inter-VM communication interface.

Qubes OS exploits this interface and wrote lightweight GUI protocol
on top of that and other lightweight communication messaging.

See https://wiki.qubes-os.org/

IIUC even NetBSD doesn't have vmchannel driver ready :(

j.

Re: making firefox less insecure

[Jonathan Thornburg]

In message 
I wrote:
> Web browsers scare me: they're huge pieces of code, un-audited, they
> have embedded Turing-complete interpreters, they live in a horribly
> imsecure environment, [[...]]
> 
> So, I'm thinking about how to exploit-mitigate a web browser (I'll use
> firefox here for purposes of illustration, but this is basically generic
> to any other web browser).  This is in the context of a single-user
> OpenBSD desktop (say a laptop).
> [[...]]
> 
> I can see several possible forms of exploit-mitigation:
> (a) use the noscript firefox extension to block javascript
> (b) use capsicum to sandbox forefox and any plugin processes
> (c) run firefox in a chroot jail
> (d) have firefox talk to an Xephyr(1) instance
> so it's semi-isolated from the main X server
> (e) maybe have firefox go through an ssh tunnel to localhost
> (f) run firefox as an unpriviliged user _firefox, group _firefox, and
> use Unix file permissions to deny that user access to $HOME/

Thank you to everyone who's responded!

Daniel Dickman pointed to the quark formally-verified web browser.
This is interesting research... but if I'm reading their paper correctly,
their formally-verified security properties still permit the browser
to (for example) send my ~/.ssh/ private keys to evil.com. :(  I'm not
sure whether these properties block the installation of keyloggers,
either.

Jorge Gabriel Lopez Paramount's idea of putting the web browser inside
a read-only virtual machine is clever.  Virtual machines have lots of
security holes (http://marc.info/?l=openbsd-misc&m=119318909016582&w=1
and http://xenbits.xen.org/xsa/), but making the VM read-only and/or
re-installing it often should mitigate that to some extent.



I now have (e) and (f) running ok on 5.6-stable, on a Thinkpad T60
laptop (3GB RAM, 2.0GHz Intel Core Duo).  My normal login is in login
class 'staff', for which I've upped the memory limits to infinity.
I've installed the firefox-31.0 package, and created a new unpriviliged
user _firefox (group _firefox and no other groups, login class staff).

Some further details:

The obvious way of doing (f) is to make either the firefox binary,
or a wrapper program, setuid/setgid _firefox.  Unfortunately, it turns
out that that doesn't drop supplementary group ids.  That is, if my
normal id is in group wheel, then even after executing a setuid/setgid
wrapper, the process is still in group wheel. :(

Since Perl (unlike shells) allows safe setuid scripts, I thought of
using the Perl Proc::UID perl module.  Alas, this is broken -- it won't
compile on any modern perl, and the bugs in question have been open with
no change in status for > 3 years.

So... back to C.  After a bit of poking around with setgroups(2), I
found that the wrapper has to be setuid/setgid root in order to be allowed
to drop the supplemental groups.  Following Chen, Wagner, & Dean's
paper "Setuid Demystified"
  http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
and inspired by /usr/src/usr.sbin/ntp.c lines 145-148, I wound up with
the following wrapper:

--- begin wrapper ---
#include 
#include 
#include 

#define ERROR_EXIT_STATUS   1
#define PROGRAM_TO_EXECUTE  "/usr/bin/id"

/*
 * This wrapper
 * - drops any supplementary groups
 * - changes to uid & gid _firefox, and
 * - executes another program
 */
int main(void)
{
/* FIXME: should really look these up via getpwnam(3) and getgrnam(3) */
const uid_t firefox_euid = 2000;
const gid_t firefox_egid = 2000;

const int my_euid = geteuid();
const int my_egid = getegid();
printf("in wrapper before dropping privs: my_euid=%d, my_egid=%d\n",
   (int) my_euid, (int) my_egid);

printf("dropping any supplementary groups...\n");
if (setgroups(0, NULL) != 0)
{
perror("unable to drop supplementary groups");
return ERROR_EXIT_STATUS;
}

printf("setting gid to _firefox...\n");
if (setresgid(firefox_egid, firefox_egid, firefox_egid) != 0)
{
perror("unable to set firefox group id");
return ERROR_EXIT_STATUS;
}

printf("setting uid to _firefox...\n");
if (setresuid(firefox_euid, firefox_euid, firefox_euid) != 0)
{
perror("unable to set firefox user id");
return ERROR_EXIT_STATUS;
}

printf("executing %s\n", PROGRAM_TO_EXECUTE);
execl(PROGRAM_TO_EXECUTE, PROGRAM_TO_EXECUTE, NULL);

/* we only get to here if the execl() failed */
perror("unable to execute");
return ERROR_EXIT_STATUS;
}
--- end wrapper ---

If compiled and made setuid-root and setgid-wheel, this successfully
drops all its priviliges (including supplemental groups).

But, when I changed /usr/bin/id to (say) /usr/X11R6/bin/xterm or
/usr/X11R6/bin/xclock (for testing), I then found that the X server
(rightfully) refuses to accept a connection from a process running
with uid/gid _firefox.  I played around a bit with copying my .Xauthority
file to the _firefox home directory, but couldn't get that 

Re: making firefox less insecure

[Jorge Gabriel Lopez Paramount]

Quoting frantisek holop :


Jorge Gabriel Lopez Paramount, 16 Nov 2014 15:55:

>Seems heavy, and probably harder to set up and maintain than (e) and (f).

Sure it's harder to set up, but believe me, after setting up the maintenance
is almost zero. I restart every week that server as read-write to patch it


as if the browsers weren't memory hungry enough, and slow:
so let's throw them inside a VM that is another pile of
huge unadited codebase (especially when the guest is
linux)?


What can I say, I reserved 800 Mb. for the virtual machine running  
only Firefox. Bur to me it has a nice extra: I have an old netbook  
with an atom processor and 1 Gb. of RAM that I use on bed, and using  
the VM browser on it is very pleasant, not sluggish as you might  
expect of an old netbook. Another good extra is that I have the same  
browser with the same settings no matter what computer (in my home) I  
use.


Did I mention that I'm new to OpenBSD?=)


the browsing experience of resource hungry sites on older
generation notebooks is abismal as it is, a VM is hardly
the solution for me.


It's as you say, but I have a resourceful "server" reserved for  
virtual machines and laptops that I use mostly to open terminals and  
remote sessions.



regarding the ssh key stealing, they are password
protected anyway, right?


I did not get this, but the only password in that VM is the root one  
and is different of the others, and that VM is not accessible outside  
my home.


Best regards,
Jorge.


This message was sent using IMP, the Internet Messaging Program.

Re: making firefox less insecure

[frantisek holop]

Jorge Gabriel Lopez Paramount, 16 Nov 2014 15:55:
> >Seems heavy, and probably harder to set up and maintain than (e) and (f).
> 
> Sure it's harder to set up, but believe me, after setting up the maintenance
> is almost zero. I restart every week that server as read-write to patch it

as if the browsers weren't memory hungry enough, and slow:
so let's throw them inside a VM that is another pile of
huge unadited codebase (especially when the guest is
linux)?

the browsing experience of resource hungry sites on older
generation notebooks is abismal as it is, a VM is hardly
the solution for me.

it is true that noscript needs handholding, and not all
sites subscribe to the philosophy of graceful degradation
of user experience when javascript is disabled, but
together with urlfilter they pack a punch and serves my
needs well.

if your bank serves you exploits through javascript,
you have bigger things to worry about than your $HOME :)
and probably should change your bank asap.

regarding the ssh key stealing, they are password
protected anyway, right?

-f
-- 
atheism is a non-prophet organization.

Re: making firefox less insecure

[Jorge Gabriel Lopez Paramount]

I use bookmarks, but I have them in my Drupal portal so no need to remember 
links, that by the way is restricted using apache authentication. The basic 
idea is this: any time I need to set something in Firefox I have to restart the 
VM as read-write, and while on it do not open any site. The first days I did 
that frequently, but last time I set something in Firefox was months ago.

Best regards,
Jorge.

Worik Stanton  wrote:

>On 17/11/14 10:55, Jorge Gabriel Lopez Paramount wrote:
>[snip]
>> I restart every week that server as read-write to patch it and that's
>> all,
>
>[snip]
>
>> I have been using that VM more than half a year and invested like 4
>> hours setting it up. Is it not worth 4 hours a software that you use
>> every day for things as important as banking?
>
>So you do not have bookmarks?
>
>For banking that is a risk.  If you miss-type your URL you may end up on
>a phishing page.
>
>I always load my banking URL from a bookmark.
>
>Worik
>
>
>--
>Why is the legal status of chardonnay different to that of cannabis?
>   worik.stan...@gmail.com 021-1680650, (03) 4821804
>  Aotearoa (New Zealand)
> I voted for love
>
>[demime 1.01d removed an attachment of type application/pgp-signature which 
>had a name of signature.asc]

Re: making firefox less insecure

[Worik Stanton]

On 17/11/14 10:55, Jorge Gabriel Lopez Paramount wrote:
[snip]
> I restart every week that server as read-write to patch it and that's
> all,

[snip]

> I have been using that VM more than half a year and invested like 4
> hours setting it up. Is it not worth 4 hours a software that you use
> every day for things as important as banking?

So you do not have bookmarks?

For banking that is a risk.  If you miss-type your URL you may end up on
a phishing page.

I always load my banking URL from a bookmark.

Worik


--
Why is the legal status of chardonnay different to that of cannabis?
   worik.stan...@gmail.com 021-1680650, (03) 4821804
  Aotearoa (New Zealand)
 I voted for love

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: making firefox less insecure

[Duncan Patton a Campbell]

Altho' I'm currently just using a) and don't do things like banking,
(rather go check out the tellers if I've got to do banking...
eases the agravation) I think that c would be reasonable if 
you had an automated setup that had already identified the 
dependancies firefox has.  This would allow reinstancing 
the setup much like the VM method described. 

Dhu

On Sun, 16 Nov 2014 14:08:39 -0500
Jonathan Thornburg  wrote:

> Web browsers scare me: they're huge pieces of code, un-audited, they
> have embedded Turing-complete interpreters, they live in a horribly
> imsecure environment,
>   [I have to put in a plug here for James Mickens' classic
>   rant "To Wash It All Aawy" (Usenix ;login, March 2014, p.2-8):
>   https://www.usenix.org/system/files/1403_02-08_mickens.pdf
>   ]
> they pass untrusted data to image/audio/video plugins which are also
> huge/unaudited/buggy, etc etc.
> 
> So, I'm thinking about how to exploit-mitigate a web browser (I'll use
> firefox here for purposes of illustration, but this is basically generic
> to any other web browser).  This is in the context of a single-user
> OpenBSD desktop (say a laptop).
> 
> My threat model is basically:
> * I run firefox
> * by default, the firefox process (and any plugins) all run under
>   my id, with the same priviliges I have
> * I browse to a (unknown-to-me) hostile website
> * hostile website exploits a vulnerability in firefox or plugin to
>   run malicious code on my computer (with all the priviliges of the
>   firefox process)
> * malicious code can then
>   - read and/or write my $HOME/.ssh/
>   - create a transparent X window over the entire screen to act as
> a keylogger to watch for the next time I type a credit card number
> or login to a banking site
>   - write to my login scripts to make that keylogger persistent
>   - try to exploit vulnerabilities in my X server
>   - if I'm in group wsrc, try to install a backdoor in /usr/src/*
>   - if I'm in group wheel, try to sudo to root to install a rootkit
>   - etc etc
> 
> I can see several possible forms of exploit-mitigation:
> (a) use the noscript firefox extension to block javascript
> (b) use capsicum to sandbox forefox and any plugin processes
> (c) run firefox in a chroot jail
> (d) have firefox talk to an Xephyr(1) instance
> so it's semi-isolated from the main X server
> (e) maybe have firefox go through an ssh tunnel to localhost
> (f) run firefox as an unpriviliged user _firefox, group _firefox, and
> use Unix file permissions to deny that user access to $HOME/
> 
> (a) works and offers a fair bit of protection until some site that
> I whitelist has a drive-by exploit. :(  And noscript requires considerable
> handholding in practice.
> 
> (b) and (c) could offer a lot of protection... but they would be a lot
> of work to port/setup, probably more work than I can afford right now.
> 
> (d) seems promising; I don't know what it would do to the ability
> to cut-and-paste between firefox and the outside world
> 
> I'm not sure if (e) is needed in combination with (d) in order to
> block firefox from connecting to the main X server.
> 
> (f) seems pretty easy, and offers some (modest) protection.
> I have some technical questions about doing that, which I'll save
> for a seprate thread.
> 
> Some useful past discussions on this mailing list include
>   http://marc.info/?l=openbsd-misc&m=126116965209030&w=1
>   http://marc.info/?l=openbsd-misc&m=135442405732373&w=1
>   http://marc.info/?l=openbsd-misc&m=135569662813122&w=1
>   http://marc.info/?l=openbsd-misc&m=135767126712239&w=1
>   http://marc.info/?l=openbsd-misc&m=135767705914968&w=1
>   http://marc.info/?l=openbsd-misc&m=135771549729476&w=1
>   http://marc.info/?l=openbsd-misc&m=135771660029742&w=1
> 
> So.
> 
> Are there other practical ways of securing an OpenBSD web browser?
> [I'm afraid "just say no" fails the "practical" test. :( ]
> 
> What unobvious gotchas are there in (d), (e), and (f)?
> Other tips-and-tricks?
> 
> ciao,
> 
> -- 
> -- "Jonathan Thornburg [remove -animal to reply]" 
> 
>Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
>"There was of course no way of knowing whether you were being watched
> at any given moment.  How often, or on what system, the Thought Police
> plugged in on any individual wire was guesswork.  It was even conceivable
> that they watched everybody all the time."  -- George Orwell, "1984"
> 
> 


-- 
Ne obliviscaris, vix ea nostra voco.

Re: making firefox less insecure

[Jorge Gabriel Lopez Paramount]

Quoting Jason Adams :


On 11/16/2014 12:15 PM, Jorge Gabriel Lopez Paramount wrote:
I have other approach that has worked for me so far: I created a  
virtual machine with Debian
GNU/kFreeBSD (sorry but I'm new here), and installed Firefox there  
and other software I would need
like image and PDF viewers. After installing Firefox I configured  
things like proxy and after

browsing no page at all shutdown my virtual machine.


Seems heavy, and probably harder to set up and maintain than (e) and (f).


Sure it's harder to set up, but believe me, after setting up the  
maintenance is almost zero. I restart every week that server as  
read-write to patch it and that's all, and have to do that way because  
Debian publish a lot of patches frequently. If OpenBSD is as good as I  
have seen and there is a patch like once a month then you will have to  
care about it once a month.


I have been using that VM more than half a year and invested like 4  
hours setting it up. Is it not worth 4 hours a software that you use  
every day for things as important as banking?


Best regards,
Jorge.


This message was sent using IMP, the Internet Messaging Program.

Re: making firefox less insecure

[Jason Adams]

On 11/16/2014 12:15 PM, Jorge Gabriel Lopez Paramount wrote:
> I have other approach that has worked for me so far: I created a virtual 
> machine with Debian
> GNU/kFreeBSD (sorry but I'm new here), and installed Firefox there and other 
> software I would need
> like image and PDF viewers. After installing Firefox I configured things like 
> proxy and after
> browsing no page at all shutdown my virtual machine. 

Seems heavy, and probably harder to set up and maintain than (e) and (f).

But I'll admit I've used a similar approach for quick and dirty short term 
solutions.
I was thinking JT was suggesting something that could be easy to set up and
maintain, requiring only setting gid/uid on the browser executable, and some 
light
scripting.



-- 
Those who do not understand Unix are condemned to reinvent it, poorly.

Re: making firefox less insecure

[Jason Adams]

On 11/16/2014 11:08 AM, Jonathan Thornburg wrote:
> (e) maybe have firefox go through an ssh tunnel to localhost
> (f) run firefox as an unpriviliged user _firefox, group _firefox, and
> use Unix file permissions to deny that user access to $HOME/

I think these two in conjunction would be sufficient to block a large majority 
of
the possible attacks.

(f) is going to require some segregated file structure as a substitute for
user's home, for cache, downloads, etc. probably that structure needs to
be owned by user with a group_firefox.

I've often worried about browsers, even the open source ones.


-- 
Those who do not understand Unix are condemned to reinvent it, poorly.

Re: making firefox less insecure

[Jorge Gabriel Lopez Paramount]

Quoting Daniel Dickman :


On Sun, Nov 16, 2014 at 2:08 PM, Jonathan Thornburg
 wrote:

Are there other practical ways of securing an OpenBSD web browser?
[I'm afraid "just say no" fails the "practical" test. :( ]



one practical thing I'd love to see is for someone to port the Quark
web browser:
http://goto.ucsd.edu/quark/

I've no idea if it's good enough for practical use, but it seems like
an interesting piece of work.


I have other approach that has worked for me so far: I created a  
virtual machine with Debian GNU/kFreeBSD (sorry but I'm new here), and  
installed Firefox there and other software I would need like image and  
PDF viewers. After installing Firefox I configured things like proxy  
and after browsing no page at all shutdown my virtual machine.


Then I start it as read-only, I mean, you can use the virtual machine  
as read-write but everything is gone after shutting it down and goes  
back to the initial state. I restart it at midnight every day so I  
have a newly-installed browser every morning, and I use the browser by  
ssh.


So far the biggest drawback to me is not being able to have sound, but  
even videos play good enough through the network. If that VM becomes  
compromised it will go back to its initial state at midnight, and it's  
isolated and with no personal data so a compromise would be very  
likely harmless.


Best regards,
Jorge.


This message was sent using IMP, the Internet Messaging Program.

Re: making firefox less insecure

[Daniel Dickman]

On Sun, Nov 16, 2014 at 2:08 PM, Jonathan Thornburg
 wrote:
> Web browsers scare me: they're huge pieces of code, un-audited, they
> have embedded Turing-complete interpreters, they live in a horribly
> imsecure environment,

[...snip...]

>
> Are there other practical ways of securing an OpenBSD web browser?
> [I'm afraid "just say no" fails the "practical" test. :( ]
>

one practical thing I'd love to see is for someone to port the Quark
web browser:
http://goto.ucsd.edu/quark/

I've no idea if it's good enough for practical use, but it seems like
an interesting piece of work.

making firefox less insecure

[Jonathan Thornburg]

Web browsers scare me: they're huge pieces of code, un-audited, they
have embedded Turing-complete interpreters, they live in a horribly
imsecure environment,
[I have to put in a plug here for James Mickens' classic
rant "To Wash It All Aawy" (Usenix ;login, March 2014, p.2-8):
https://www.usenix.org/system/files/1403_02-08_mickens.pdf
]
they pass untrusted data to image/audio/video plugins which are also
huge/unaudited/buggy, etc etc.

So, I'm thinking about how to exploit-mitigate a web browser (I'll use
firefox here for purposes of illustration, but this is basically generic
to any other web browser).  This is in the context of a single-user
OpenBSD desktop (say a laptop).

My threat model is basically:
* I run firefox
* by default, the firefox process (and any plugins) all run under
  my id, with the same priviliges I have
* I browse to a (unknown-to-me) hostile website
* hostile website exploits a vulnerability in firefox or plugin to
  run malicious code on my computer (with all the priviliges of the
  firefox process)
* malicious code can then
  - read and/or write my $HOME/.ssh/
  - create a transparent X window over the entire screen to act as
a keylogger to watch for the next time I type a credit card number
or login to a banking site
  - write to my login scripts to make that keylogger persistent
  - try to exploit vulnerabilities in my X server
  - if I'm in group wsrc, try to install a backdoor in /usr/src/*
  - if I'm in group wheel, try to sudo to root to install a rootkit
  - etc etc

I can see several possible forms of exploit-mitigation:
(a) use the noscript firefox extension to block javascript
(b) use capsicum to sandbox forefox and any plugin processes
(c) run firefox in a chroot jail
(d) have firefox talk to an Xephyr(1) instance
so it's semi-isolated from the main X server
(e) maybe have firefox go through an ssh tunnel to localhost
(f) run firefox as an unpriviliged user _firefox, group _firefox, and
use Unix file permissions to deny that user access to $HOME/

(a) works and offers a fair bit of protection until some site that
I whitelist has a drive-by exploit. :(  And noscript requires considerable
handholding in practice.

(b) and (c) could offer a lot of protection... but they would be a lot
of work to port/setup, probably more work than I can afford right now.

(d) seems promising; I don't know what it would do to the ability
to cut-and-paste between firefox and the outside world

I'm not sure if (e) is needed in combination with (d) in order to
block firefox from connecting to the main X server.

(f) seems pretty easy, and offers some (modest) protection.
I have some technical questions about doing that, which I'll save
for a seprate thread.

Some useful past discussions on this mailing list include
  http://marc.info/?l=openbsd-misc&m=126116965209030&w=1
  http://marc.info/?l=openbsd-misc&m=135442405732373&w=1
  http://marc.info/?l=openbsd-misc&m=135569662813122&w=1
  http://marc.info/?l=openbsd-misc&m=135767126712239&w=1
  http://marc.info/?l=openbsd-misc&m=135767705914968&w=1
  http://marc.info/?l=openbsd-misc&m=135771549729476&w=1
  http://marc.info/?l=openbsd-misc&m=135771660029742&w=1

So.

Are there other practical ways of securing an OpenBSD web browser?
[I'm afraid "just say no" fails the "practical" test. :( ]

What unobvious gotchas are there in (d), (e), and (f)?
Other tips-and-tricks?

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" 

   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
at any given moment.  How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork.  It was even conceivable
that they watched everybody all the time."  -- George Orwell, "1984"