edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev] zip and security
@ 2018-03-05 22:17 Karl Dahlke
  2018-03-05 22:32 ` Dominique Martinet
  0 siblings, 1 reply; 3+ messages in thread
From: Karl Dahlke @ 2018-03-05 22:17 UTC (permalink / raw)
  To: Edbrowse-dev

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

Here is something funny, so terribly unlikely that I'm not gonna worry about it, but there's always a way, isn't there.

Suppose Fred knows all about edbrowse, and millions of people are using edbrowse (instead of 15),
and he knows a lot of us use the plugins in the wiki to access zip files.
He writes a web page with javascript that does an xhr request to
zipxd://foo.zip@:@top
If anything is found, the javascript sends it back to the server for analysis.
Or maybe the script traverses the entire tree in the zip archive and sends all the files to the server.
Now I say it's unlikely because the web page would have to know the name of your zip file, i.e. the path to your zip file, and at least one directory.
In my example it has to know there is foo.zip in your current directory and it has a directory inside it called top.
There aren't any standard zip files in standard places on unix machines, so I guess we're all right.
I just looked under /bin /lib /usr /etc and found none.

Karl Dahlke

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Edbrowse-dev] zip and security
  2018-03-05 22:17 [Edbrowse-dev] zip and security Karl Dahlke
@ 2018-03-05 22:32 ` Dominique Martinet
  2018-03-05 23:35   ` Kevin Carhart
  0 siblings, 1 reply; 3+ messages in thread
From: Dominique Martinet @ 2018-03-05 22:32 UTC (permalink / raw)
  To: Karl Dahlke; +Cc: Edbrowse-dev

Karl Dahlke wrote on Mon, Mar 05, 2018:
> He writes a web page with javascript that does an xhr request to
> zipxd://foo.zip@:@top

I think it's a matter of priority, but now we have javascript working a
bit better we might soon find time to make it more restricted somehow.

I still think allowing any site to do xhr requests anywhere is not
something we will want.
I started writing a mail about this ages ago (August last year!) and it
is actually still open despite me not having written a word there in at
least six months, that shows how often this machines reboots, but joke
aside I think we now have enough js that old attacks on firefox would
work on edbrowse, so we will need to start worrying about it sooner or
later...

As you said most of these attacks depend on having millions of users,
but you can also see it differently and having one user exposed to a
million of attacks and it might work.
A classical example is just assuming you have a comcast home router at
192.168.1.1 (or whatever the default address is) and with the default
user admin/admin, just do a xhr for http://admin:admin@192.168.1.1/page
where page could open up firewall or change your password or brick the
modem - remember I assumed comcast so I can look up these pages.

I'm sure that even with just 15 users one of us might be in that
configuration!


I don't have any easy solution, I started looking up everything firefox
does and there is no end, we probably do not need everything, but there
is some food for thought.
-- 
Dominique | Asmadeus

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Edbrowse-dev] zip and security
  2018-03-05 22:32 ` Dominique Martinet
@ 2018-03-05 23:35   ` Kevin Carhart
  0 siblings, 0 replies; 3+ messages in thread
From: Kevin Carhart @ 2018-03-05 23:35 UTC (permalink / raw)
  To: Edbrowse-dev

On Mon, 5 Mar 2018, Dominique Martinet wrote:

> Karl Dahlke wrote on Mon, Mar 05, 2018:
>> He writes a web page with javascript that does an xhr request to
>> zipxd://foo.zip@:@top
>
> I think it's a matter of priority, but now we have javascript working a
> bit better we might soon find time to make it more restricted somehow.
>
> I still think allowing any site to do xhr requests anywhere is not
> something we will want.

I completely agree.  For a long time we've been in a pocket.  It didn't 
matter that much because we didn't have a lot of pages that were getting 
all the way through the several steps of retrieving responseText, going to 
a callback, processing the content, and innerHTML side effects take it 
back to EBML.  (!)  It's very exciting that we started to get this, so 
congratulations, our prize for breaking through is a new tier of robust 
worries..

I could write the same-origin restriction into javascript.  Not that this 
covers it entirely, but at least the default would be strict and we would 
block some opportunists.  Suppose I have just loaded abc.com, and I 
instantiate a new XHRHttpRequest object.  I try to retrieve a page from 
def.com.  Should I intercept this in javascript before it gets to 
fetchHTTP, and fail silently?  Or throw something?






> I started writing a mail about this ages ago (August last year!) and it

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-03-05 23:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-05 22:17 [Edbrowse-dev] zip and security Karl Dahlke
2018-03-05 22:32 ` Dominique Martinet
2018-03-05 23:35   ` Kevin Carhart

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).