Re: Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
On Wednesday 31 October 2007 15:34:18 Gregory Fleischer (Lists) wrote:
> Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
> an insecure configuration file. Both Windows and Mac OS X versions
> are affected. The installed 'config.txt' file ('config' on Mac OS X)
> had the following option values set to 1:
>
>- enable-remote-toggle
>- enable-edit-actions
>
>
> In order to allow time for people to upgrade, additional attack
> details and sample code will be withheld for a couple of days.
TorK is affected by this too. There should be a 0.22 available before Friday.
signature.asc
Description: This is a digitally signed message part.
Re: Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
"Kyle Williams" <[EMAIL PROTECTED]> wrote:
> On 10/31/07, Gregory Fleischer (Lists) <[EMAIL PROTECTED]> wrote:
> > Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
> > an insecure configuration file. Both Windows and Mac OS X versions
> > are affected. The installed 'config.txt' file ('config' on Mac OS X)
> > had the following option values set to 1:
> >
> >- enable-remote-toggle
> >- enable-edit-actions
> >
> > Additionally, on Windows the following option was set to 1:
> >
> >- enable-remote-http-toggle
> >
> > Malicious sites (or malicious exit nodes) could include active content
> > (e.g., JavaScript, Java, Flash) that caused the web browser to:
> >
> >- make requests through the proxy that causes Privoxy filtering to
> > be bypassed or completely disabled
> >
> >- establish a direct connection from the web browser to the local
> > proxy and modify the user defined configuration values
> I know what that code would be (cause I tried this awhile back), but I'm not
> going to be the one to post it. Although anyone with basic HTML coding
> abilities and half a brain can figure it out. And javascript/java/flash
> isn't required to make this happen. It can be done with a simple IFRAME.
> But I'm not posting the one line of HTML code that would do this, no sir.
> We noted this a while back with JanusVM, but I don't think we documented the
> reasoning behind it.
Let me get this straight. A while ago, you found a vulnerability that
allows an attacker to change Privoxy's action files without relying on
the user to execute untrusted code, but decided not to report it to the
Privoxy Team and/or the people behind the Vidalia bundle and instead
only fixed it in your own Tor+Privoxy distribution?
Is there a remote chance that you could come around to
do the right thing and report it now?
Fabian
signature.asc
Description: PGP signature
Re: Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
On 10/31/07, Gregory Fleischer (Lists) <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
> an insecure configuration file. Both Windows and Mac OS X versions
> are affected. The installed 'config.txt' file ('config' on Mac OS X)
> had the following option values set to 1:
>
>- enable-remote-toggle
>- enable-edit-actions
>
> Additionally, on Windows the following option was set to 1:
>
>- enable-remote-http-toggle
>
> Malicious sites (or malicious exit nodes) could include active content
> (e.g., JavaScript, Java, Flash) that caused the web browser to:
>
>- make requests through the proxy that causes Privoxy filtering to
> be bypassed or completely disabled
>
>- establish a direct connection from the web browser to the local
> proxy and modify the user defined configuration values
>
> The Privoxy documentation recommends against enabling these options in
> multi-user environments or when dealing with untrustworthy clients.
> However, the documentation does not mention that client-side
> web browser scripts or vulnerabilities could be exploited as well.
>
> It should be noted that using Tor is not a prerequisite for some of
> these attacks to be successful. Users of Tor may be at greater risk,
> because malicious exit nodes can inject content into otherwise trusted
> sites.
>
> In order to allow time for people to upgrade, additional attack
> details and sample code will be withheld for a couple of days.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHKKB6WbVJrJm/lrsRApQLAKC5FRcVsCuBBxtSxnmbl0ihixaX3gCfZHZ8
> gwXIIv2LUswWy1bSwg5CJU4=
> =ZSdL
> -END PGP SIGNATURE-
>
I know what that code would be (cause I tried this awhile back), but I'm not
going to be the one to post it. Although anyone with basic HTML coding
abilities and half a brain can figure it out. And javascript/java/flash
isn't required to make this happen. It can be done with a simple IFRAME.
But I'm not posting the one line of HTML code that would do this, no sir.
We noted this a while back with JanusVM, but I don't think we documented the
reasoning behind it.
(Cue Roger giving a friendly reminder to get more documentation and source
code produced ;-)
First we disabled those options for obvious reasons.
Then we enabled them because a couple of users wanted more control.
Then we disabled them again because that level of control can be accessed
from the console if they really want it.
Fun times.
Insecure Privoxy Configuration in Vidalia Bundles Prior to 0.1.2.18
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
an insecure configuration file. Both Windows and Mac OS X versions
are affected. The installed 'config.txt' file ('config' on Mac OS X)
had the following option values set to 1:
- enable-remote-toggle
- enable-edit-actions
Additionally, on Windows the following option was set to 1:
- enable-remote-http-toggle
Malicious sites (or malicious exit nodes) could include active content
(e.g., JavaScript, Java, Flash) that caused the web browser to:
- make requests through the proxy that causes Privoxy filtering to
be bypassed or completely disabled
- establish a direct connection from the web browser to the local
proxy and modify the user defined configuration values
The Privoxy documentation recommends against enabling these options in
multi-user environments or when dealing with untrustworthy clients.
However, the documentation does not mention that client-side
web browser scripts or vulnerabilities could be exploited as well.
It should be noted that using Tor is not a prerequisite for some of
these attacks to be successful. Users of Tor may be at greater risk,
because malicious exit nodes can inject content into otherwise trusted
sites.
In order to allow time for people to upgrade, additional attack
details and sample code will be withheld for a couple of days.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHKKB6WbVJrJm/lrsRApQLAKC5FRcVsCuBBxtSxnmbl0ihixaX3gCfZHZ8
gwXIIv2LUswWy1bSwg5CJU4=
=ZSdL
-END PGP SIGNATURE-
