Mailing List Archive

Filezilla's silent caching of user's credentials
Hi all,

As some of you may or may not be aware, the popular (and IMHO one of the best) FTP/SCP program Filezilla caches your credentials for every host you connect to, without either warning or ability to change this without editing an XML file. There have been quite a few bug and features requests filed, and they all get closed or rejected within a week or so. I also posted something in the developer forum inquiring about this, and received this response:

"I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be."

Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)

To me this is not only concerning, but also completely un-acceptable. The passwords all get stored in PLAIN TEXT within your %appdata% directory in an XML file. This is particularly dangerous in multi-user environments with local profiles, because as we all know physical access to a computer means it's elementary at best to acquire information off it. Permissions only work if your operating system chooses to respect them, not to mention how simple it is *even today* to maliciously get around windows networks using pass-the-hash along with network token manipulation techniques.

There has even been a bug filed that draws out great ways to psudo-mitigate this using built-in windows API calls, but it doesn't seem to really be going anywhere. This really concerns me because a number of my coworkers and friends were un-aware of this behavior, and I didn't even know about it until I'd been using it for a year or so. All I really want to see is at the very least just some warning that Filezilla does this.

Filezilla bug report:(http://trac.filezilla-project.org/ticket/5530)

My feelings have been said a lot more eloquently than I could ever hope to in that bug report:

"Whoever keeps closing this issue and/or dismissing its importance understands neither security nor logical argument. I apologize for the slam, but it is undeniably true. Making the same mistake over and over does not make it any less of a mistake. The fact that a critical deficiency has existed for years does not make it any less critical a deficiency. Similarly, the fact that there are others (pidgin) who indulge in the same faulty reasoning does not make the reasoning any more sound." ~btrower

While it's true you can mitigate this behavior, why should it even be enabled by default? The total lapse in security for such a feature-rich, robust piece of software is quite disturbing, and I don't understand how the developers don't think this is an issue.

I just wanted to gauge the FD community on this issue, because with enough backing and explanation from the security community as to why this is a problem, this issue may finally be resolved (it's been doing this for years now).

Regards,
Ryan Sears

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
I agree. I've always wondered why this information was stored in plain
text...baffles me

--
Sent from my Droid Incredible
Virtuous ROM v3.0.1
On Oct 7, 2010 11:22 PM, "Ryan Sears" <rdsears@mtu.edu> wrote:
> Hi all,
>
> As some of you may or may not be aware, the popular (and IMHO one of the
best) FTP/SCP program Filezilla caches your credentials for every host you
connect to, without either warning or ability to change this without editing
an XML file. There have been quite a few bug and features requests filed,
and they all get closed or rejected within a week or so. I also posted
something in the developer forum inquiring about this, and received this
response:
>
> "I do not see any harm in storing credentials as long as the rest of your
system is properly secure as it should be."
>
> Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
>
> To me this is not only concerning, but also completely un-acceptable. The
passwords all get stored in PLAIN TEXT within your %appdata% directory in an
XML file. This is particularly dangerous in multi-user environments with
local profiles, because as we all know physical access to a computer means
it's elementary at best to acquire information off it. Permissions only work
if your operating system chooses to respect them, not to mention how simple
it is *even today* to maliciously get around windows networks using
pass-the-hash along with network token manipulation techniques.
>
> There has even been a bug filed that draws out great ways to
psudo-mitigate this using built-in windows API calls, but it doesn't seem to
really be going anywhere. This really concerns me because a number of my
coworkers and friends were un-aware of this behavior, and I didn't even know
about it until I'd been using it for a year or so. All I really want to see
is at the very least just some warning that Filezilla does this.
>
> Filezilla bug report:(http://trac.filezilla-project.org/ticket/5530)
>
> My feelings have been said a lot more eloquently than I could ever hope to
in that bug report:
>
> "Whoever keeps closing this issue and/or dismissing its importance
understands neither security nor logical argument. I apologize for the slam,
but it is undeniably true. Making the same mistake over and over does not
make it any less of a mistake. The fact that a critical deficiency has
existed for years does not make it any less critical a deficiency.
Similarly, the fact that there are others (pidgin) who indulge in the same
faulty reasoning does not make the reasoning any more sound." ~btrower
>
> While it's true you can mitigate this behavior, why should it even be
enabled by default? The total lapse in security for such a feature-rich,
robust piece of software is quite disturbing, and I don't understand how the
developers don't think this is an issue.
>
> I just wanted to gauge the FD community on this issue, because with enough
backing and explanation from the security community as to why this is a
problem, this issue may finally be resolved (it's been doing this for years
now).
>
> Regards,
> Ryan Sears
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
http://www.google.com/#sclient=psy&hl=en&site=&source=hp&q=inurl:recentservers.xml&oq=inurl:recentservers.xml

:)



From:
Ryan Sears <rdsears@mtu.edu>
To:
full-disclosure <full-disclosure@lists.grok.org.uk>
Date:
10/08/2010 08:52 AM
Subject:
[Full-disclosure] Filezilla's silent caching of user's credentials
Sent by:
full-disclosure-bounces@lists.grok.org.uk



Hi all,

As some of you may or may not be aware, the popular (and IMHO one of the
best) FTP/SCP program Filezilla caches your credentials for every host you
connect to, without either warning or ability to change this without
editing an XML file. There have been quite a few bug and features requests
filed, and they all get closed or rejected within a week or so. I also
posted something in the developer forum inquiring about this, and received
this response:

"I do not see any harm in storing credentials as long as the rest of your
system is properly secure as it should be."

Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)

To me this is not only concerning, but also completely un-acceptable. The
passwords all get stored in PLAIN TEXT within your %appdata% directory in
an XML file. This is particularly dangerous in multi-user environments
with local profiles, because as we all know physical access to a computer
means it's elementary at best to acquire information off it. Permissions
only work if your operating system chooses to respect them, not to mention
how simple it is *even today* to maliciously get around windows networks
using pass-the-hash along with network token manipulation techniques.

There has even been a bug filed that draws out great ways to
psudo-mitigate this using built-in windows API calls, but it doesn't seem
to really be going anywhere. This really concerns me because a number of
my coworkers and friends were un-aware of this behavior, and I didn't even
know about it until I'd been using it for a year or so. All I really want
to see is at the very least just some warning that Filezilla does this.

Filezilla bug report:(http://trac.filezilla-project.org/ticket/5530)

My feelings have been said a lot more eloquently than I could ever hope to
in that bug report:

"Whoever keeps closing this issue and/or dismissing its importance
understands neither security nor logical argument. I apologize for the
slam, but it is undeniably true. Making the same mistake over and over
does not make it any less of a mistake. The fact that a critical
deficiency has existed for years does not make it any less critical a
deficiency. Similarly, the fact that there are others (pidgin) who indulge
in the same faulty reasoning does not make the reasoning any more sound."
~btrower

While it's true you can mitigate this behavior, why should it even be
enabled by default? The total lapse in security for such a feature-rich,
robust piece of software is quite disturbing, and I don't understand how
the developers don't think this is an issue.

I just wanted to gauge the FD community on this issue, because with enough
backing and explanation from the security community as to why this is a
problem, this issue may finally be resolved (it's been doing this for
years now).

Regards,
Ryan Sears

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Re: Filezilla's silent caching of user's credentials [ In reply to ]
Fillzilla stores the credentials with no warning, default behavior.

Fillzilla does not have an option to disable this.

Fillzilla will "clear" private data, but forensics will of course
find it.

Yucky behavior. Bad developer.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
Hi Ryan,

No inline comments. Sorry (I wanted to reorder topics).

> I just wanted to gauge the FD community on this issue, because
> with enough backing and explanation from the security community
> as to why this is a problem, this issue may finally be resolved (it's
> been doing this for years now)
This is an alarming trend in open source software, and diametrically
opposed to the claims of "more eyes equates to more secure"", "open
source software is more secure", and "open source software fixes bugs
faster than other software models".

Is also blows away the theory of "Darwinian Software Evolution": good,
robust, secure software thrives and lesser software dies. Filezilla
and the Python example below are "proofs by counter example". It
appears the model in use is greatly influenced by popularity, which
makes it more appropriate for politicians (who tend to lie for a
living) ;)

> "I do not see any harm in storing credentials as long as the rest
> of your system is properly secure as it should be."
> Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
That should earn the project a Pwnie Award nomination for lamest
vendor response (http://pwnies.com/).

> To me this is not only concerning, but also completely un-acceptable.
Agreed.

Other recent similar examples of this sort of response by open source
projects include "Python ssl handling could be better...", where the
Python Standard Library did not (still does not?) verify the hostname
in the certificate with CN or SubAlt name
(http://seclists.org/fulldisclosure/2010/Sep/381). The python bug was
filed in 2007 (http://bugs.python.org/issue1589).

Jeff

On Thu, Oct 7, 2010 at 11:10 PM, Ryan Sears <rdsears@mtu.edu> wrote:
> Hi all,
>
> As some of you may or may not be aware, the popular (and IMHO one of the best) FTP/SCP program Filezilla caches your credentials for every host you connect to, without either warning or ability to change this without editing an XML file. There have been quite a few bug and features requests filed, and they all get closed or rejected within a week or so. I also posted something in the developer forum inquiring about this, and received this response:
>
> "I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be."
>
> Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
>
> To me this is not only concerning, but also completely un-acceptable. The passwords all get stored in PLAIN TEXT within your %appdata% directory in an XML file. This is particularly dangerous in multi-user environments with local profiles, because as we all know physical access to a computer means it's elementary at best to acquire information off it. Permissions only work if your operating system chooses to respect them, not to mention how simple it is *even today* to maliciously get around windows networks using pass-the-hash along with network token manipulation techniques.
>
> There has even been a bug filed that draws out great ways to psudo-mitigate this using built-in windows API calls, but it doesn't seem to really be going anywhere. This really concerns me because a number of my coworkers and friends were un-aware of this behavior, and I didn't even know about it until I'd been using it for a year or so. All I really want to see is at the very least just some warning that Filezilla does this.
>
> Filezilla bug report:(http://trac.filezilla-project.org/ticket/5530)
>
> My feelings have been said a lot more eloquently than I could ever hope to in that bug report:
>
> "Whoever keeps closing this issue and/or dismissing its importance understands neither security nor logical argument. I apologize for the slam, but it is undeniably true. Making the same mistake over and over does not make it any less of a mistake. The fact that a critical deficiency has existed for years does not make it any less critical a deficiency. Similarly, the fact that there are others (pidgin) who indulge in the same faulty reasoning does not make the reasoning any more sound." ~btrower
>
> While it's true you can mitigate this behavior, why should it even be enabled by default? The total lapse in security for such a feature-rich, robust piece of software is quite disturbing, and I don't understand how the developers don't think this is an issue.
>
> I just wanted to gauge the FD community on this issue, because with enough backing and explanation from the security community as to why this is a problem, this issue may finally be resolved (it's been doing this for years now).
>
> Regards,
> Ryan Sears
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Thu, Oct 7, 2010 at 11:10 PM, Ryan Sears <rdsears@mtu.edu> wrote:
> Hi all,
>
> As some of you may or may not be aware, the popular (and
> IMHO one of the best) FTP/SCP program Filezilla caches your
> credentials for every host you connect to, without either warning
> or ability to change this without editing an XML file. There have
> been quite a few bug and features requests filed, and they all
> get closed or rejected within a week or so. I also posted
> something in the developer forum inquiring about this, and
> received this response:
>
> "I do not see any harm in storing credentials as long as the
> rest of your system is properly secure as it should be."
> Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
>
> [SNIP]
>
> I just wanted to gauge the FD community on this issue,
> because with enough backing and explanation from the
> security community as to why this is a problem, this issue
> may finally be resolved (it's been doing this for years now).

Am I the only person who finds it ironic that the same measures
leveraged against closed source projects have to be employed against
some open source projects?

Jeff

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
No one really cares about session keys or credentials:

http://www.google.com/search?q=%22Apache+Server+Status+for%22+%22Server+Version%22+-%22How+to%22+-Guide+-Tuning&hl=en&biw=1430&bih=789&ei=KQOvTPv-Oo_Jswb7oJHTDQ&start=10&sa=N

27,800 hits..

This is a missconfiguration done by the administrator.

So i like that quote:

"I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be."


"Let He Who Is Without Sin Cast The First Stone"




--- Jeffrey Walton <noloader@gmail.com> schrieb am Fr, 8.10.2010:

> Von: Jeffrey Walton <noloader@gmail.com>
> Betreff: Re: [Full-disclosure] Filezilla's silent caching of user's credentials
> An: "Ryan Sears" <rdsears@mtu.edu>
> CC: "full-disclosure" <full-disclosure@lists.grok.org.uk>
> Datum: Freitag, 8. Oktober, 2010 02:25 Uhr
> Hi Ryan,
>
> No inline comments. Sorry (I wanted to reorder topics).
>
> > I just wanted to gauge the FD community on this issue,
> because
> > with enough backing and explanation from the security
> community
> > as to why this is a problem, this issue may finally be
> resolved (it's
> > been doing this for years now)
> This is an alarming trend in open source software, and
> diametrically
> opposed to the claims of "more eyes equates to more
> secure"", "open
> source software is more secure", and "open source software
> fixes bugs
> faster than other software models".
>
> Is also blows away the theory of "Darwinian Software
> Evolution": good,
> robust, secure software thrives and lesser software dies.
> Filezilla
> and the Python example below are "proofs by counter
> example". It
> appears the model in use is greatly influenced by
> popularity, which
> makes it more appropriate for politicians (who tend to lie
> for a
> living) ;)
>
> > "I do not see any harm in storing credentials as long
> as the rest
> > of your system is properly secure as it should be."
> > Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
> That should earn the project a Pwnie Award nomination for
> lamest
> vendor response (http://pwnies.com/).
>
> > To me this is not only concerning, but also completely
> un-acceptable.
> Agreed.
>
> Other recent similar examples of this sort of response by
> open source
> projects include "Python ssl handling could be better...",
> where the
> Python Standard Library did not (still does not?) verify
> the hostname
> in the certificate with CN or SubAlt name
> (http://seclists.org/fulldisclosure/2010/Sep/381). The
> python bug was
> filed in 2007 (http://bugs.python.org/issue1589).
>
> Jeff
>
> On Thu, Oct 7, 2010 at 11:10 PM, Ryan Sears <rdsears@mtu.edu>
> wrote:
> > Hi all,
> >
> > As some of you may or may not be aware, the popular
> (and IMHO one of the best) FTP/SCP program Filezilla caches
> your credentials for every host you connect to, without
> either warning or ability to change this without editing an
> XML file. There have been quite a few bug and features
> requests filed, and they all get closed or rejected within a
> week or so. I also posted something in the developer forum
> inquiring about this, and received this response:
> >
> > "I do not see any harm in storing credentials as long
> as the rest of your system is properly secure as it should
> be."
> >
> > Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
> >
> > To me this is not only concerning, but also completely
> un-acceptable. The passwords all get stored in PLAIN TEXT
> within your %appdata% directory in an XML file. This is
> particularly dangerous in multi-user environments with local
> profiles, because as we all know physical access to a
> computer means it's elementary at best to acquire
> information off it. Permissions only work if your operating
> system chooses to respect them, not to mention how simple it
> is *even today* to maliciously get around windows networks
> using pass-the-hash along with network token manipulation
> techniques.
> >
> > There has even been a bug filed that draws out great
> ways to psudo-mitigate this using built-in windows API
> calls, but it doesn't seem to really be going anywhere. This
> really concerns me because a number of my coworkers and
> friends were un-aware of this behavior, and I didn't even
> know about it until I'd been using it for a year or so. All
> I really want to see is at the very least just some warning
> that Filezilla does this.
> >
> > Filezilla bug report:(http://trac.filezilla-project.org/ticket/5530)
> >
> > My feelings have been said a lot more eloquently than
> I could ever hope to in that bug report:
> >
> > "Whoever keeps closing this issue and/or dismissing
> its importance understands neither security nor logical
> argument. I apologize for the slam, but it is undeniably
> true. Making the same mistake over and over does not make it
> any less of a mistake. The fact that a critical deficiency
> has existed for years does not make it any less critical a
> deficiency. Similarly, the fact that there are others
> (pidgin) who indulge in the same faulty reasoning does not
> make the reasoning any more sound." ~btrower
> >
> > While it's true you can mitigate this behavior, why
> should it even be enabled by default? The total lapse in
> security for such a feature-rich, robust piece of software
> is quite disturbing, and I don't understand how the
> developers don't think this is an issue.
> >
> > I just wanted to gauge the FD community on this issue,
> because with enough backing and explanation from the
> security community as to why this is a problem, this issue
> may finally be resolved (it's been doing this for years
> now).
> >
> > Regards,
> > Ryan Sears
> >
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Thu, Oct 7, 2010 at 11:10 PM, Ryan Sears <rdsears@mtu.edu> wrote:
> Hi all,
>
> As some of you may or may not be aware, the popular (and IMHO one of the best) FTP/SCP program Filezilla caches your credentials for every host you connect to, without either warning or ability to change this without editing an XML file. There have been quite a few bug and features requests filed, and they all get closed or rejected within a week or so. I also posted something in the developer forum inquiring about this, and received this response:
>
> "I do not see any harm in storing credentials as long as the rest of your system is properly secure as it should be."
>
> Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
>
> To me this is not only concerning, but also completely un-acceptable. The passwords all get stored in PLAIN TEXT within your %appdata% directory in an XML file. This is particularly dangerous in multi-user environments with local profiles, because as we all know physical access to a computer means it's elementary at best to acquire information off it. Permissions only work if your operating system chooses to respect them, not to mention how simple it is *even today* to maliciously get around windows networks using pass-the-hash along with network token manipulation techniques.
>

I reported a similar issue in a certain SSH client a few years ago, it
was keeping the passphrase as cleartext in memory
for the duration of the session as well as an arbitrarily long period
after you disconnect but keep the window open.

They added protections like a simple encoding for the credentials
where they are stored, and nulling out the region
when you ended the session. They still wanted to keep the credentials
intact during the session in order to quickly
create new terminal windows.

This issue was much less serious than storing the cleartext in a file,
and they thought it appropriate to add protections.

>
> I just wanted to gauge the FD community on this issue, because with enough backing and explanation from the security community as to why this is a problem, this issue may finally be resolved (it's been doing this for years now).
>

It IS an issue. Plain and simple.

That type of developer response really gets me.

Personally I won't be allowing Filezilla on any of my systems even if
they do eventually patch this issue..
who knows what else is lurking behind the scenes?

Cheers,
Charles

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
food for thought:
https://bugzilla.mozilla.org/show_bug.cgi?id=602181

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
That's a live and good example. I hope that now they'll understand the
importance of the issue.

On Fri, Oct 8, 2010 at 11:28 AM, Shirish Padalkar
<shirish.padalkar@tcs.com>wrote:

>
>
> http://www.google.com/#sclient=psy&hl=en&site=&source=hp&q=inurl:recentservers.xml&oq=inurl:recentservers.xml
>
> :)
>
>
> From:
> Ryan Sears <rdsears@mtu.edu>
> To:
> full-disclosure <full-disclosure@lists.grok.org.uk>
> Date: 10/08/2010 08:52 AM Subject:
> [Full-disclosure] Filezilla's silent caching of user's credentials
> Sent by: full-disclosure-bounces@lists.grok.org.uk
> ------------------------------
>
>
>
> Hi all,
>
> As some of you may or may not be aware, the popular (and IMHO one of the
> best) FTP/SCP program Filezilla caches your credentials for every host you
> connect to, without either warning or ability to change this without editing
> an XML file. There have been quite a few bug and features requests filed,
> and they all get closed or rejected within a week or so. I also posted
> something in the developer forum inquiring about this, and received this
> response:
>
> "I do not see any harm in storing credentials as long as the rest of your
> system is properly secure as it should be."
>
> Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
>
> To me this is not only concerning, but also completely un-acceptable. The
> passwords all get stored in PLAIN TEXT within your %appdata% directory in an
> XML file. This is particularly dangerous in multi-user environments with
> local profiles, because as we all know physical access to a computer means
> it's elementary at best to acquire information off it. Permissions only work
> if your operating system chooses to respect them, not to mention how simple
> it is *even today* to maliciously get around windows networks using
> pass-the-hash along with network token manipulation techniques.
>
> There has even been a bug filed that draws out great ways to psudo-mitigate
> this using built-in windows API calls, but it doesn't seem to really be
> going anywhere. This really concerns me because a number of my coworkers and
> friends were un-aware of this behavior, and I didn't even know about it
> until I'd been using it for a year or so. All I really want to see is at the
> very least just some warning that Filezilla does this.
>
> Filezilla bug report:(http://trac.filezilla-project.org/ticket/5530)
>
> My feelings have been said a lot more eloquently than I could ever hope to
> in that bug report:
>
> "Whoever keeps closing this issue and/or dismissing its importance
> understands neither security nor logical argument. I apologize for the slam,
> but it is undeniably true. Making the same mistake over and over does not
> make it any less of a mistake. The fact that a critical deficiency has
> existed for years does not make it any less critical a deficiency.
> Similarly, the fact that there are others (pidgin) who indulge in the same
> faulty reasoning does not make the reasoning any more sound." ~btrower
>
> While it's true you can mitigate this behavior, why should it even be
> enabled by default? The total lapse in security for such a feature-rich,
> robust piece of software is quite disturbing, and I don't understand how the
> developers don't think this is an issue.
>
> I just wanted to gauge the FD community on this issue, because with enough
> backing and explanation from the security community as to why this is a
> problem, this issue may finally be resolved (it's been doing this for years
> now).
>
> Regards,
> Ryan Sears
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>



--
Thanks and Regards,
Vipul Agarwal
Re: Filezilla's silent caching of user's credentials [ In reply to ]
What do you mean by that? There have been a *lot* of good points made through this whole thing, both on the list, and in the forums.

This is a multi-tiered issue, both in the fact that it stores your credentials, and the fact that it does so in a very insecure manner.

As with any program there are scenarios in which you're forced to log into secured resources in a 'less-than-secure' way. Maybe someone is middling your connection? Maybe someone has a metasploit dll agent hiding in your filezilla.exe process sniffing for keystrokes? It happens, thanks to windows' plethora of 'features'.

However with the right measures it can be tougher to leverage. Everything is psudo security by obscurity in one way or another when you think about it. Imagine encryption as a needle in a haystack, but instead of a needle you're looking for a single atom, and instead of a haystack you're looking at every single atom on the face of the planet (please correct me if I'm mistaken in this point. I am by no means a crypto expert).

The only way to be really secure is run FreeBSD on a computer not plugged into any network and uses absolutely nothing external (usb drives, etc). Then it becomes a trade-off in usefulness. Also what happens when someone discovers a 0-day in BSD?

Security is a constant up-hill battle, which is why I find it so interesting. Very smart people are *always* coming up with more creative ways to manipulate systems of *any* kind. All you can do is learn as much as you can about how they're doing it, and come up with any mitigations you can.

Ryan


----- Original Message -----
From: "Chris Evans" <scarybeasts@gmail.com>
To: "Mutiny" <mutiny@kevinbeardsucks.com>
Cc: full-disclosure@lists.grok.org.uk
Sent: Wednesday, October 13, 2010 6:32:14 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] Filezilla's silent caching of user's credentials


Finally, a note of sanity in this thread.


On Tue, Oct 12, 2010 at 8:33 PM, Mutiny < mutiny@kevinbeardsucks.com > wrote:


The issue is that someone gained access to that file. You sharing your
drives over the internet with read privileges? You have other
vulnerable software being leveraged to read that file? Would you prefer
they MD5'd it? It sounds like your issue is that your password is
stored. I mean, they moved your encrypted password from passwd to
shadow for a reason, but that doesn't change the fact that it's stored
and if someone doesn't need access to shadow or passwd, they shouldn't
have it.

Stop logging into your FTP server from a public terminal with Filezilla.



On 10/9/2010 11:00 AM, Vipul Agarwal wrote:



> That's a live and good example. I hope that now they'll understand the
> importance of the issue.
>
> On Fri, Oct 8, 2010 at 11:28 AM, Shirish Padalkar
> < shirish.padalkar@tcs.com >wrote:
>
>>
>>
>> http://www.google.com/#sclient=psy&hl=en&site=&source=hp&q=inurl:recentservers.xml&oq=inurl:recentservers.xml
>>
>> :)
>>
>>
>> From:
>> Ryan Sears < rdsears@mtu.edu >
>> To:
>> full-disclosure < full-disclosure@lists.grok.org.uk >
>> Date: 10/08/2010 08:52 AM Subject:
>> [Full-disclosure] Filezilla's silent caching of user's credentials
>> Sent by: full-disclosure-bounces@lists.grok.org.uk
>> ------------------------------
>>
>>
>>
>> Hi all,
>>
>> As some of you may or may not be aware, the popular (and IMHO one of the
>> best) FTP/SCP program Filezilla caches your credentials for every host you
>> connect to, without either warning or ability to change this without editing
>> an XML file. There have been quite a few bug and features requests filed,
>> and they all get closed or rejected within a week or so. I also posted
>> something in the developer forum inquiring about this, and received this
>> response:
>>
>> "I do not see any harm in storing credentials as long as the rest of your
>> system is properly secure as it should be."
>>
>> Source:( http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932 )
>>
>> To me this is not only concerning, but also completely un-acceptable. The
>> passwords all get stored in PLAIN TEXT within your %appdata% directory in an
>> XML file. This is particularly dangerous in multi-user environments with
>> local profiles, because as we all know physical access to a computer means
>> it's elementary at best to acquire information off it. Permissions only work
>> if your operating system chooses to respect them, not to mention how simple
>> it is *even today* to maliciously get around windows networks using
>> pass-the-hash along with network token manipulation techniques.
>>
>> There has even been a bug filed that draws out great ways to psudo-mitigate
>> this using built-in windows API calls, but it doesn't seem to really be
>> going anywhere. This really concerns me because a number of my coworkers and
>> friends were un-aware of this behavior, and I didn't even know about it
>> until I'd been using it for a year or so. All I really want to see is at the
>> very least just some warning that Filezilla does this.
>>
>> Filezilla bug report:( http://trac.filezilla-project.org/ticket/5530 )
>>
>> My feelings have been said a lot more eloquently than I could ever hope to
>> in that bug report:
>>
>> "Whoever keeps closing this issue and/or dismissing its importance
>> understands neither security nor logical argument. I apologize for the slam,
>> but it is undeniably true. Making the same mistake over and over does not
>> make it any less of a mistake. The fact that a critical deficiency has
>> existed for years does not make it any less critical a deficiency.
>> Similarly, the fact that there are others (pidgin) who indulge in the same
>> faulty reasoning does not make the reasoning any more sound." ~btrower
>>
>> While it's true you can mitigate this behavior, why should it even be
>> enabled by default? The total lapse in security for such a feature-rich,
>> robust piece of software is quite disturbing, and I don't understand how the
>> developers don't think this is an issue.
>>
>> I just wanted to gauge the FD community on this issue, because with enough
>> backing and explanation from the security community as to why this is a
>> problem, this issue may finally be resolved (it's been doing this for years
>> now).
>>
>> Regards,
>> Ryan Sears
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>> =====-----=====-----=====
>> Notice: The information contained in this e-mail
>> message and/or attachments to it may contain
>> confidential or privileged information. If you are
>> not the intended recipient, any dissemination, use,
>> review, distribution, printing or copying of the
>> information contained in this e-mail message
>> and/or attachments to it are strictly prohibited. If
>> you have received this communication in error,
>> please notify us by reply e-mail or telephone and
>> immediately and permanently delete the message
>> and any attachments. Thank you
>>
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
If the encryption key stays on the same PC, there is absolutely no security
in that. Given that this is open source, security through obscurity can't
even start working (-> encrypting local files with a local key / using
custom algo == security through obscurity).

I think it ought to stay plaintext and people limit access to this file
whenever possible.
It's hardly a trivial matter to delete this file....if an attacker can
search for and read this file, a user could search for the same file and
delete it.

Fortunately, for the poor souls out there that allow read access to their
drives, computer forensics haven't caught up yet (and probably won't in the
near future).

My 2 cents.

Chris.



On Thu, Oct 14, 2010 at 12:41 AM, silky <michaelslists@gmail.com> wrote:

> On Wed, Oct 13, 2010 at 2:33 PM, Mutiny <mutiny@kevinbeardsucks.com>
> wrote:
> > The issue is that someone gained access to that file. You sharing your
> > drives over the internet with read privileges? You have other
> > vulnerable software being leveraged to read that file? Would you prefer
> > they MD5'd it? It sounds like your issue is that your password is
> > stored. I mean, they moved your encrypted password from passwd to
> > shadow for a reason, but that doesn't change the fact that it's stored
> > and if someone doesn't need access to shadow or passwd, they shouldn't
> > have it.
> >
> > Stop logging into your FTP server from a public terminal with Filezilla.
>
> Rubbish.
>
> The passwords should be encoded so-as to avoid trivial searching. End
> of story. It takes 10 minutes to do from a development point of view,
> and there is no excuse.
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Thu, Oct 14, 2010 at 10:57 AM, Christian Sciberras <uuf6429@gmail.com> wrote:
> If the encryption key stays on the same PC, there is absolutely no security
> in that. Given that this is open source, security through obscurity can't
> even start working (-> encrypting local files with a local key / using
> custom algo == security through obscurity).

No, you are completely wrong and I encourage you to specifically
consider a layered threat model or perhaps just read the information
*already presented* in this thread. Not all attackers are created
equally.

There is no question here. There is no discussion. It should be done,
and if it is not, password saving should be stopped in FileZilla or an
alternative program should be sought. It's that simple.

(Note that BeyondCompare and probably at least N other programs out
there *do* perform a trivial encoding of the passwords, and it is a
good and appropriate policy).


> Chris.

--
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Wed, 13 Oct 2010 18:49:59 EDT, Ryan Sears said:

> The only way to be really secure is run FreeBSD on a computer not plugged
> into any network and uses absolutely nothing external (usb drives, etc). Then
> it becomes a trade-off in usefulness. Also what happens when someone discovers
> a 0-day in BSD?

Actually, the adage used to be "the only safe computer is a powered-down
computer". And even that's not perfect - some very clever guys at UIUC managed
to get a quantum CPU that wasn't powered on to do some calculations *anyhow*:

http://blogs.discovermagazine.com/cosmicvariance/2006/02/28/paul-kwiat-on-quantum-computation/
(the original link at New Scientist seems to have gone belly-up)

Now, if the program run while it's turned off has an exploitable bug in it.....
Re: Filezilla's silent caching of user's credentials [ In reply to ]
> Not all attackers are created
> equally.

I still see this a simple matter of violating KISS to introduce a layer of
encryption.
The question is, to which end? Sure, an attacker might see the encrypted
file
and think it's "too difficult" for him to get to the passwords. Another
might use
a certain utility to decrypt the said file. The thing is, to which end are
we encrypting
the data? Just for the sake of making it work like the N other programs?
I mean, if this doesn't *work*, why even *bother*?

> There is no question here. There is no discussion. It should be done,
> and if it is not, password saving should be stopped in FileZilla or an
> alternative program should be sought. It's that simple.

Great. If it's so simple that it can be done in under 10 mins, go complain
to them.

As to "go read our awesome security standards we created", that is the exact
reason
why I consider this "security feature" completely useless.

Cheers,
Chris.







On Thu, Oct 14, 2010 at 2:08 AM, silky <michaelslists@gmail.com> wrote:

> On Thu, Oct 14, 2010 at 10:57 AM, Christian Sciberras <uuf6429@gmail.com>
> wrote:
> > If the encryption key stays on the same PC, there is absolutely no
> security
> > in that. Given that this is open source, security through obscurity can't
> > even start working (-> encrypting local files with a local key / using
> > custom algo == security through obscurity).
>
> No, you are completely wrong and I encourage you to specifically
> consider a layered threat model or perhaps just read the information
> *already presented* in this thread. Not all attackers are created
> equally.
>
> There is no question here. There is no discussion. It should be done,
> and if it is not, password saving should be stopped in FileZilla or an
> alternative program should be sought. It's that simple.
>
> (Note that BeyondCompare and probably at least N other programs out
> there *do* perform a trivial encoding of the passwords, and it is a
> good and appropriate policy).
>
>
> > Chris.
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras <uuf6429@gmail.com> wrote:
> > Not all attackers are created
> > equally.
>
> I still see this a simple matter of violating KISS to introduce a layer of encryption.
> The question is, to which end? Sure, an attacker might see the encrypted
> file and think it's "too difficult" for him to get to the passwords. Another
> might use a certain utility to decrypt the said file. The thing is, to which end are
> we encrypting the data? Just for the sake of making it work like the N other programs?
> I mean, if this doesn't *work*, why even *bother*?

Sorry, but your comments are totally useless here and can't even
really be addressed properly, given their quite ridiculous nature. You
are missing the point of the encryption, and it is not my job to
convince you, and any further comments with anyone other than the
developer are useless.


> > There is no question here. There is no discussion. It should be done,
> > and if it is not, password saving should be stopped in FileZilla or an
> > alternative program should be sought. It's that simple.
>
> Great. If it's so simple that it can be done in under 10 mins, go complain
> to them.

This email thread *is* a direct complaint to them, after bugs have
been closed for years. I didn't start this thread. Do you even
understand what is going on here? Your emails suggest you do not.


> Cheers,
> Chris.


--
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
Yeah I definitely have to go with silky on this one.

Maybe if you elaborate on your point? I'm not sure I entirely grasp what you're trying to say, because if I am, then you share relatively the same view as the dev that's causing this problem. You can argue that any security measure "doesn't *work*" as you so put it, given the right circumstances.

Take handcuffs for example, what good would they be if when you put them on, you could never get them off again? Sure they would "work", but there's no mechanism to UNsecure them, which is where vulnerabilities in security systems inherently exist. The handcuff design is flawed on a fundamental level as they can be easily shimmed by manipulating the way they lock into place. That's when the double-lock came into play, which is a very, very simple example of layered security. While the handcuffs are double-locked the teeth can't progress in any direction, because it locks that mechanism into place. This is undone by turning the key in the opposite direction to release the 'double-lock' then back forward to release the teeth. Call that two-factor authentication. That's all fair and well, but there are STILL ways to manipulate them to get out. What happens if you have a key (which is pretty much universal)? It's even been demonstrated that most handcuffs can be picked with a simple bobby pin. Are handcuffs pointless though? No. They've been demonstrated time and time again to be 'good enough'.

My point is, the KISS principal doesn't really hold true here. Encryption schemes are MEANT to be complex in nature (at least one-way), because that's the only way to make sure that something is properly secured. Botg DID have encryption at some point, but he did away with it after people found it was easily reversed. (http://seclists.org/fulldisclosure/2005/Sep/50)

The idea that just because an encryption scheme may be reversed at some point it shouldn't be used is *absolutely* terrible practice. Shadow passwords are a great example, while they have the ability to be cracked, they're still a de facto standard for authentication in *any* unix environment. There's a reason for this. That's why people created the crypt() function, and that's why the windows API has stuff to do this natively as well.

As for change proposals, I did the digging, and found that 90% of all this crap would be avoided with a single 0->1 change in the source code. If 'kiosk-mode' was enabled by default, you could at least have the OPTION to use piss-poor practices to store your passwords if you so choose. (http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932&start=15)

I've made my final plea to botg on this issue, and if he's not going to budge I'll be forced to take measures into my own hands and change the damn source myself.

Thankfully the rest of the world doesn't share your (& botg's) opinions, because if they did, hacking wouldn't be any fun.

Ryan

----- Original Message -----
From: "silky" <michaelslists@gmail.com>
To: "Christian Sciberras" <uuf6429@gmail.com>
Cc: full-disclosure@lists.grok.org.uk, "Mutiny" <mutiny@kevinbeardsucks.com>
Sent: Thursday, October 14, 2010 2:46:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] Filezilla's silent caching of user's credentials

On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras <uuf6429@gmail.com> wrote:
> > Not all attackers are created
> > equally.
>
> I still see this a simple matter of violating KISS to introduce a layer of encryption.
> The question is, to which end? Sure, an attacker might see the encrypted
> file and think it's "too difficult" for him to get to the passwords. Another
> might use a certain utility to decrypt the said file. The thing is, to which end are
> we encrypting the data? Just for the sake of making it work like the N other programs?
> I mean, if this doesn't *work*, why even *bother*?

Sorry, but your comments are totally useless here and can't even
really be addressed properly, given their quite ridiculous nature. You
are missing the point of the encryption, and it is not my job to
convince you, and any further comments with anyone other than the
developer are useless.


> > There is no question here. There is no discussion. It should be done,
> > and if it is not, password saving should be stopped in FileZilla or an
> > alternative program should be sought. It's that simple.
>
> Great. If it's so simple that it can be done in under 10 mins, go complain
> to them.

This email thread *is* a direct complaint to them, after bugs have
been closed for years. I didn't start this thread. Do you even
understand what is going on here? Your emails suggest you do not.


> Cheers,
> Chris.


--
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
My point is, if you are granting access to this password file to everyone,
the security hassles you're going through are all useless.
I mean, ok, you might prevent script kiddies (or lazy hackers) from getting
to the passwords, but discrimination is not the point of security is it?

With regards to the handcuffs example, yes let's. They're no use if the
criminal with the handcuff is situated in the red district and won't budge
out of there.
I think it's the context that makes this work. Users/admins should be
limiting access to the passwords file in the first place.

So far the security flaws we've seen (with this bad practice of using
plaintext) is people happily handing out passwords.
OK, encrypting the file would have prevented this mess - somewhat.
Better still, they shouldn't be handing out the file in the first place.

@Chris/silky - I didn't ask for your comments - maybe you didn't realize,
yours are just as useless.
No not in the theoretical context you keep coming up with, they *are* really
useless.
I mean, arguments like "you are shit, without doubts", really won't get you
anywhere.

@Ryan - I don't need to take to anyone's defence. As you correctly said, any
security precaution might not work when put through certain conditions.
Maybe it's just my opinion, I don't know. But the problem I see is people
shouldn't be assuming something is safe and hand it out.
Sharing a whole hard drive with the web doesn't sound like a smart idea to
me.


Cheers,
Chris.




On Thu, Oct 14, 2010 at 9:16 AM, Ryan Sears <rdsears@mtu.edu> wrote:

> Yeah I definitely have to go with silky on this one.
>
> Maybe if you elaborate on your point? I'm not sure I entirely grasp what
> you're trying to say, because if I am, then you share relatively the same
> view as the dev that's causing this problem. You can argue that any security
> measure "doesn't *work*" as you so put it, given the right circumstances.
>
> Take handcuffs for example, what good would they be if when you put them
> on, you could never get them off again? Sure they would "work", but there's
> no mechanism to UNsecure them, which is where vulnerabilities in security
> systems inherently exist. The handcuff design is flawed on a fundamental
> level as they can be easily shimmed by manipulating the way they lock into
> place. That's when the double-lock came into play, which is a very, very
> simple example of layered security. While the handcuffs are double-locked
> the teeth can't progress in any direction, because it locks that mechanism
> into place. This is undone by turning the key in the opposite direction to
> release the 'double-lock' then back forward to release the teeth. Call that
> two-factor authentication. That's all fair and well, but there are STILL
> ways to manipulate them to get out. What happens if you have a key (which is
> pretty much universal)? It's even been demonstrated that most handcuffs can
> be picked with a simple bobby pin. Are handcuffs pointless though? No.
> They've been demonstrated time and time again to be 'good enough'.
>
> My point is, the KISS principal doesn't really hold true here. Encryption
> schemes are MEANT to be complex in nature (at least one-way), because that's
> the only way to make sure that something is properly secured. Botg DID have
> encryption at some point, but he did away with it after people found it was
> easily reversed. (http://seclists.org/fulldisclosure/2005/Sep/50)
>
> The idea that just because an encryption scheme may be reversed at some
> point it shouldn't be used is *absolutely* terrible practice. Shadow
> passwords are a great example, while they have the ability to be cracked,
> they're still a de facto standard for authentication in *any* unix
> environment. There's a reason for this. That's why people created the
> crypt() function, and that's why the windows API has stuff to do this
> natively as well.
>
> As for change proposals, I did the digging, and found that 90% of all this
> crap would be avoided with a single 0->1 change in the source code. If
> 'kiosk-mode' was enabled by default, you could at least have the OPTION to
> use piss-poor practices to store your passwords if you so choose. (
> http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932&start=15)
>
> I've made my final plea to botg on this issue, and if he's not going to
> budge I'll be forced to take measures into my own hands and change the damn
> source myself.
>
> Thankfully the rest of the world doesn't share your (& botg's) opinions,
> because if they did, hacking wouldn't be any fun.
>
> Ryan
>
> ----- Original Message -----
> From: "silky" <michaelslists@gmail.com>
> To: "Christian Sciberras" <uuf6429@gmail.com>
> Cc: full-disclosure@lists.grok.org.uk, "Mutiny" <
> mutiny@kevinbeardsucks.com>
> Sent: Thursday, October 14, 2010 2:46:13 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [Full-disclosure] Filezilla's silent caching of user's
> credentials
>
> On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras <uuf6429@gmail.com>
> wrote:
> > > Not all attackers are created
> > > equally.
> >
> > I still see this a simple matter of violating KISS to introduce a layer
> of encryption.
> > The question is, to which end? Sure, an attacker might see the encrypted
> > file and think it's "too difficult" for him to get to the passwords.
> Another
> > might use a certain utility to decrypt the said file. The thing is, to
> which end are
> > we encrypting the data? Just for the sake of making it work like the N
> other programs?
> > I mean, if this doesn't *work*, why even *bother*?
>
> Sorry, but your comments are totally useless here and can't even
> really be addressed properly, given their quite ridiculous nature. You
> are missing the point of the encryption, and it is not my job to
> convince you, and any further comments with anyone other than the
> developer are useless.
>
>
> > > There is no question here. There is no discussion. It should be done,
> > > and if it is not, password saving should be stopped in FileZilla or an
> > > alternative program should be sought. It's that simple.
> >
> > Great. If it's so simple that it can be done in under 10 mins, go
> complain
> > to them.
>
> This email thread *is* a direct complaint to them, after bugs have
> been closed for years. I didn't start this thread. Do you even
> understand what is going on here? Your emails suggest you do not.
>
>
> > Cheers,
> > Chris.
>
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Wed, Oct 13, 2010 at 11:46 PM, silky <michaelslists@gmail.com> wrote:

> On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras <uuf6429@gmail.com>
> wrote:
> > > Not all attackers are created
> > > equally.
> >
> > I still see this a simple matter of violating KISS to introduce a layer
> of encryption.
> > The question is, to which end? Sure, an attacker might see the encrypted
> > file and think it's "too difficult" for him to get to the passwords.
> Another
> > might use a certain utility to decrypt the said file. The thing is, to
> which end are
> > we encrypting the data? Just for the sake of making it work like the N
> other programs?
> > I mean, if this doesn't *work*, why even *bother*?
>
> Sorry, but your comments are totally useless here and can't even
> really be addressed properly, given their quite ridiculous nature.


Well done on behaving in a gentlemanly manner and winning people over with
your in-depth technical arguments.

I think you need to break down the problem into the various threats against
these stored secrets.

1) You're worried about some random person who has transient physical access
to your logged-in machine.

2) You're worried about some sophisticated actor who has transient physical
access to your machine.

3) You're worried about your machine getting stolen, or improper disposal of
your hard drive.

4) You're worried about the worst-possible impact of a file-theft bug,
perhaps in a browser.

5) You're worried about having used FileZilla on a public terminal.

6) You're worried because multiple users without full trust between one
another share the same account.

Feel free to add 7), 8), etc.

Once you start breaking it down, you realize that you're completely
shit-out-of-luck in cases 2), 5) and 6); in case 1), the worst attacks
comprise of writing to the drive and not reading from it; you're negligent
if you're worried about 3) and don't have full-disk encryption; and 4) is
actually the most nuanced and interesting threat yet it doesn't seem to be
figuring in the reasoning of prior entrants to the thread.

In fact, given the current state of the security industry, I think I have
the worst threat yet:

7) You're worried about a large number of bike-shedding lower-tier security
researchers posting en-masse to f-d. You're worried that subsequent to this,
some less technical security journalists will pick up on it and write a
bunch of sensationalist news articles covering what is essentially a minor
issue.


The opening e-mail used or quoted phrases such as "critical deficiency",
"total lapse" and "quite disturbing". This shows a disappointing
misunderstanding of what "critical" really is.

This bug is not being used to break into nuclear reactors in Iran, or to
distribute mass malware. It's important to be balanced and realistic whilst
discussing security issues.


Cheers
Chris

You
> are missing the point of the encryption, and it is not my job to
> convince you, and any further comments with anyone other than the
> developer are useless.
>
>
> > > There is no question here. There is no discussion. It should be done,
> > > and if it is not, password saving should be stopped in FileZilla or an
> > > alternative program should be sought. It's that simple.
> >
> > Great. If it's so simple that it can be done in under 10 mins, go
> complain
> > to them.
>
> This email thread *is* a direct complaint to them, after bugs have
> been closed for years. I didn't start this thread. Do you even
> understand what is going on here? Your emails suggest you do not.
>
>
> > Cheers,
> > Chris.
>
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
Re: Filezilla's silent caching of user's credentials [ In reply to ]
Ah, now your point becomes clear to me.

Of course you shouldn't be granting access to that kind of stuff. That shouldn't even really need to be stated, but I whole-heartedly agree.

Rule #1 of security: You're only as secure as your weakest, and most easily manipulated layer (or link if you're using the chain example). Sadly though some mis-configurations set that kind of stuff up automatically, which is why google hacking is *so* damn effective. I wish it weren't, but it is absolutely shocking how many channels that people thought were buried can be discovered if you know how to look for it.

If Google weren't so scrupulous about filtering for automated requests, then it would definitely be (and still is) one of the easiest channels to discover vulnerabilities on a network-wide level. It *also* has the added benefit of no need to interact with the machines you're enumerating information about. Of course there are ways around google's blocking (such as using a botnet) but stuff like that is out of the usual person's grasp.

I'm not quite sure I grasp your 'red district' example, perhaps it's a difference in national slang?

Also no-one *asks* for comments. That's what happens when you talk on an un-moderated list like this.

I also think that a flame war might be brewing, but I think it was due to the unclear nature of your first post. My reaction was pretty much the same until I read it a few times, and realized that you might be un-clearly stating your point. We all agree that this is bad practice, and that's it's even WORSE practice to let the googlez index *any* files that you don't explicitly tell it to. We also agree on the "door vs. window" adage - You can buy a military-grade lock and sink all your money into a fancy door that will never be penetrated, but if you have cheap window locks, what's the point? Hopefully that helps clear up the rise in hostile feelings. It's good to see that you're both passionate about defending your points though.

Ryan

----- Original Message -----
From: "Christian Sciberras" <uuf6429@gmail.com>
To: "Ryan Sears" <rdsears@mtu.edu>
Cc: michaelslists@gmail.com, full-disclosure@lists.grok.org.uk, "Mutiny" <mutiny@kevinbeardsucks.com>
Sent: Thursday, October 14, 2010 3:32:10 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] Filezilla's silent caching of user's credentials

My point is, if you are granting access to this password file to everyone, the security hassles you're going through are all useless.
I mean, ok, you might prevent script kiddies (or lazy hackers) from getting to the passwords, but discrimination is not the point of security is it?

With regards to the handcuffs example, yes let's. They're no use if the criminal with the handcuff is situated in the red district and won't budge out of there.
I think it's the context that makes this work. Users/admins should be limiting access to the passwords file in the first place.

So far the security flaws we've seen (with this bad practice of using plaintext) is people happily handing out passwords.
OK, encrypting the file would have prevented this mess - somewhat.
Better still, they shouldn't be handing out the file in the first place.

@Chris/silky - I didn't ask for your comments - maybe you didn't realize, yours are just as useless.
No not in the theoretical context you keep coming up with, they *are* really useless.
I mean, arguments like "you are shit, without doubts", really won't get you anywhere.

@Ryan - I don't need to take to anyone's defence. As you correctly said, any security precaution might not work when put through certain conditions.
Maybe it's just my opinion, I don't know. But the problem I see is people shouldn't be assuming something is safe and hand it out.
Sharing a whole hard drive with the web doesn't sound like a smart idea to me.


Cheers,
Chris.





On Thu, Oct 14, 2010 at 9:16 AM, Ryan Sears < rdsears@mtu.edu > wrote:


Yeah I definitely have to go with silky on this one.

Maybe if you elaborate on your point? I'm not sure I entirely grasp what you're trying to say, because if I am, then you share relatively the same view as the dev that's causing this problem. You can argue that any security measure "doesn't *work*" as you so put it, given the right circumstances.

Take handcuffs for example, what good would they be if when you put them on, you could never get them off again? Sure they would "work", but there's no mechanism to UNsecure them, which is where vulnerabilities in security systems inherently exist. The handcuff design is flawed on a fundamental level as they can be easily shimmed by manipulating the way they lock into place. That's when the double-lock came into play, which is a very, very simple example of layered security. While the handcuffs are double-locked the teeth can't progress in any direction, because it locks that mechanism into place. This is undone by turning the key in the opposite direction to release the 'double-lock' then back forward to release the teeth. Call that two-factor authentication. That's all fair and well, but there are STILL ways to manipulate them to get out. What happens if you have a key (which is pretty much universal)? It's even been demonstrated that most handcuffs can be picked with a simple bobby pin. Are handcuffs pointless though? No. They've been demonstrated time and time again to be 'good enough'.

My point is, the KISS principal doesn't really hold true here. Encryption schemes are MEANT to be complex in nature (at least one-way), because that's the only way to make sure that something is properly secured. Botg DID have encryption at some point, but he did away with it after people found it was easily reversed. ( http://seclists.org/fulldisclosure/2005/Sep/50 )

The idea that just because an encryption scheme may be reversed at some point it shouldn't be used is *absolutely* terrible practice. Shadow passwords are a great example, while they have the ability to be cracked, they're still a de facto standard for authentication in *any* unix environment. There's a reason for this. That's why people created the crypt() function, and that's why the windows API has stuff to do this natively as well.

As for change proposals, I did the digging, and found that 90% of all this crap would be avoided with a single 0->1 change in the source code. If 'kiosk-mode' was enabled by default, you could at least have the OPTION to use piss-poor practices to store your passwords if you so choose. ( http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932&start=15 )

I've made my final plea to botg on this issue, and if he's not going to budge I'll be forced to take measures into my own hands and change the damn source myself.

Thankfully the rest of the world doesn't share your (& botg's) opinions, because if they did, hacking wouldn't be any fun.

Ryan


----- Original Message -----
From: "silky" < michaelslists@gmail.com >
To: "Christian Sciberras" < uuf6429@gmail.com >
Cc: full-disclosure@lists.grok.org.uk , "Mutiny" < mutiny@kevinbeardsucks.com >
Sent: Thursday, October 14, 2010 2:46:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] Filezilla's silent caching of user's credentials




On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras < uuf6429@gmail.com > wrote:
> > Not all attackers are created
> > equally.
>
> I still see this a simple matter of violating KISS to introduce a layer of encryption.
> The question is, to which end? Sure, an attacker might see the encrypted
> file and think it's "too difficult" for him to get to the passwords. Another
> might use a certain utility to decrypt the said file. The thing is, to which end are
> we encrypting the data? Just for the sake of making it work like the N other programs?
> I mean, if this doesn't *work*, why even *bother*?

Sorry, but your comments are totally useless here and can't even
really be addressed properly, given their quite ridiculous nature. You
are missing the point of the encryption, and it is not my job to
convince you, and any further comments with anyone other than the
developer are useless.


> > There is no question here. There is no discussion. It should be done,
> > and if it is not, password saving should be stopped in FileZilla or an
> > alternative program should be sought. It's that simple.
>
> Great. If it's so simple that it can be done in under 10 mins, go complain
> to them.

This email thread *is* a direct complaint to them, after bugs have
been closed for years. I didn't start this thread. Do you even
understand what is going on here? Your emails suggest you do not.


> Cheers,
> Chris.


--
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."




_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
Has anyone asked the developer to include a "don't cache credentials"
or "kiosk mode" (as someone else suggested) option even if this is not
the default at the very least it makes people aware that the passwords
are stored and may be (trivially) recoverable.

Pete

On 14 October 2010 18:51, Chris Evans <scarybeasts@gmail.com> wrote:
> On Wed, Oct 13, 2010 at 11:46 PM, silky <michaelslists@gmail.com> wrote:
>>
>> On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras <uuf6429@gmail.com>
>> wrote:
>> > > Not all attackers are created
>> > > equally.
>> >
>> > I still see this a simple matter of violating KISS to introduce a layer
>> > of encryption.
>> > The question is, to which end? Sure, an attacker might see the encrypted
>> > file and think it's "too difficult" for him to get to the passwords.
>> > Another
>> > might use a certain utility to decrypt the said file. The thing is, to
>> > which end are
>> > we encrypting the data? Just for the sake of making it work like the N
>> > other programs?
>> > I mean, if this doesn't *work*, why even *bother*?
>>
>> Sorry, but your comments are totally useless here and can't even
>> really be addressed properly, given their quite ridiculous nature.
>
> Well done on behaving in a gentlemanly manner and winning people over with
> your in-depth technical arguments.
> I think you need to break down the problem into the various threats against
> these stored secrets.
> 1) You're worried about some random person who has transient physical access
> to your logged-in machine.
> 2) You're worried about some sophisticated actor who has transient physical
> access to your machine.
> 3) You're worried about your machine getting stolen, or improper disposal of
> your hard drive.
> 4) You're worried about the worst-possible impact of a file-theft bug,
> perhaps in a browser.
> 5) You're worried about having used FileZilla on a public terminal.
> 6) You're worried because multiple users without full trust between one
> another share the same account.
> Feel free to add 7), 8), etc.
> Once you start breaking it down, you realize that you're completely
> shit-out-of-luck in cases 2), 5) and 6); in case 1), the worst attacks
> comprise of writing to the drive and not reading from it; you're negligent
> if you're worried about 3) and don't have full-disk encryption; and 4) is
> actually the most nuanced and interesting threat yet it doesn't seem to be
> figuring in the reasoning of prior entrants to the thread.
> In fact, given the current state of the security industry, I think I have
> the worst threat yet:
> 7) You're worried about a large number of bike-shedding lower-tier security
> researchers posting en-masse to f-d. You're worried that subsequent to this,
> some less technical security journalists will pick up on it and write a
> bunch of sensationalist news articles covering what is essentially a minor
> issue.
>
> The opening e-mail used or quoted phrases such as "critical deficiency",
> "total lapse" and "quite disturbing". This shows a disappointing
> misunderstanding of what "critical" really is.
> This bug is not being used to break into nuclear reactors in Iran, or to
> distribute mass malware. It's important to be balanced and realistic whilst
> discussing security issues.
>
> Cheers
> Chris
>>
>> You
>> are missing the point of the encryption, and it is not my job to
>> convince you, and any further comments with anyone other than the
>> developer are useless.
>>
>>
>> > > There is no question here. There is no discussion. It should be done,
>> > > and if it is not, password saving should be stopped in FileZilla or an
>> > > alternative program should be sought. It's that simple.
>> >
>> > Great. If it's so simple that it can be done in under 10 mins, go
>> > complain
>> > to them.
>>
>> This email thread *is* a direct complaint to them, after bugs have
>> been closed for years. I didn't start this thread. Do you even
>> understand what is going on here? Your emails suggest you do not.
>>
>>
>> > Cheers,
>> > Chris.
>>
>>
>> --
>> silky
>>
>> http://dnoondt.wordpress.com/
>>
>> "Every morning when I wake up, I experience an exquisite joy — the joy
>> of being this signature."
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Thu, Oct 14, 2010 at 6:51 PM, Chris Evans <scarybeasts@gmail.com> wrote:

[...]

>> Sorry, but your comments are totally useless here and can't even
>> really be addressed properly, given their quite ridiculous nature.
>
> Well done on behaving in a gentlemanly manner and winning people over with
> your in-depth technical arguments.

Just because someone has managed to sign up to full disclosure and
send an email doesn't entitle them to have an email from me explaining
exactly how wrong their thought processes are. My post was meant to
encourage the reader to actually try and re-evalue his position own
his own and try a little bit of self-education on the matter.

Like I said to the other guy, I really don't care if you understand
the issue.The game now (or at least here, on this list) is to try and
steer people away from FileZilla if it doesn't change. Anyones opinion
other than the developer on the issue of the nature of stored
passwords on a local machine is meaningless. If their position is
*influenced* by yours, then I will comment, otherwise, I don't see the
point.

--
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
> I'm not quite sure I grasp your 'red district' example, perhaps it's a
difference in national slang?

It's no use the criminal is handcuffed if he's not locked up in jail (or on
the way to one) - it's a matter of time for him/her sawing/picking them off.

> I also think that a flame war might be brewing

The objective was to get people like you and Evans to think about it. I
don't care if people like silky
just won't hear any reason, opinion or whatever, on the matter. Ever since
he wrote "there's no discussion", I realized he's a lost case.

----

> exactly how wrong their thought processes are. My post was meant to
> encourage the reader to actually try and re-evalue his position own
> his own and try a little bit of self-education on the matter.

That's some nice encouragement. Kind of reminds me of Windows XP's
connection troubleshooter;
"Please visit the interwebz and we'll help you connect to the internet."

Just because you signed up on FD and have a fancy blog doesn't mean you're
any better.
Really.
I wonder how many under-paid chinese hackers even own a wordpress account -
and we know how they seem to find 0days which we don't find with our fancy
tools.

> the issue.The game now (or at least here, on this list) is to try and
> steer people away from FileZilla if it doesn't change. Anyones opinion

And that is my point exactly. While I'm shouting out loud, let me ask a
question:
How many FD readers are dumb enough to share their harddisks with the world?
None? So what is the problem in using FileZilla personally? I mean, anyone
which
takes security seriously, would be encrypting their drive in the first
place.




On Thu, Oct 14, 2010 at 10:07 AM, silky <michaelslists@gmail.com> wrote:

> On Thu, Oct 14, 2010 at 6:51 PM, Chris Evans <scarybeasts@gmail.com>
> wrote:
>
> [...]
>
> >> Sorry, but your comments are totally useless here and can't even
> >> really be addressed properly, given their quite ridiculous nature.
> >
> > Well done on behaving in a gentlemanly manner and winning people over
> with
> > your in-depth technical arguments.
>
> Just because someone has managed to sign up to full disclosure and
> send an email doesn't entitle them to have an email from me explaining
> exactly how wrong their thought processes are. My post was meant to
> encourage the reader to actually try and re-evalue his position own
> his own and try a little bit of self-education on the matter.
>
> Like I said to the other guy, I really don't care if you understand
> the issue.The game now (or at least here, on this list) is to try and
> steer people away from FileZilla if it doesn't change. Anyones opinion
> other than the developer on the issue of the nature of stored
> passwords on a local machine is meaningless. If their position is
> *influenced* by yours, then I will comment, otherwise, I don't see the
> point.
>
> --
> silky
>
> http://dnoondt.wordpress.com/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
>
Re: Filezilla's silent caching of user's credentials [ In reply to ]
Ok. Granted I'm not talking about a 0-day in OpenSSH here, but this IS a real issue affecting REAL people.

I'm not really sure *who* you're trying to take a jab with point 7 and beyond, but I know at least part of it is towards me.

Filezilla's behavior is *wrong* and what I was doing was calling for a community push to actually get things changed. I was trying to state my point as clearly and concisely as I possibly could, because I feel with enough of a community backing we can actually convince botg to make minor tweaks to his source code, and come to some kind of compromise.

Show me another widely-used, widely-accepted program that really does stuff like this. I haven't really encountered them (I could be mistaken though, and I'm fine with being corrected).

I'm pretty sure you were trying to state that I was below you in some way, and I very well may be. This is a community full of people with varying degrees of technical knowledge and understanding, but we are all subscribed to this list to do one thing - learn. How do you learn? By observing. Observing folly's in the way other people have implemented things, and how people have done things right. Take the apache.org xss bug that got leveraged into a full compromise of their systems, there had to be people who were influenced to start using things like no-script because of it. Then you have the other people, who will never change their practices anyway.

It's really all about the path of exposure, going back to the apache.org thing. That was a 0-day XSS bug (which honestly isn't THAT hard to find) that was used to leverage one user's account, which then lead to something, which then lead to something else. How do you know that a nuclear scientist didn't have this exact same thing happen to them with this filezilla behavior, which then lead to a compromise of a nuclear reactor?

Just because I don't have something like 10% of all the ZDI bugs under my belt doesn't make my points any less valid. Who cares if people choose to write about it? Basically what you're saying is you're afraid of people using the internet to write about stuff they're interested in, and voice their opinions. That's in complete contradiction to the nature of this list (and the whole internet for that matter), and no matter how hard you close your eyes and wish that the internet hadn't given people an anonymous voice to bitch about what they choose, it'll never go away. That's just the way it is.

Ryan

----- Original Message -----
From: "Chris Evans" <scarybeasts@gmail.com>
To: michaelslists@gmail.com
Cc: full-disclosure@lists.grok.org.uk, "Mutiny" <mutiny@kevinbeardsucks.com>
Sent: Thursday, October 14, 2010 3:51:31 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] Filezilla's silent caching of user's credentials


On Wed, Oct 13, 2010 at 11:46 PM, silky < michaelslists@gmail.com > wrote:




On Thu, Oct 14, 2010 at 5:39 PM, Christian Sciberras < uuf6429@gmail.com > wrote:
> > Not all attackers are created
> > equally.
>
> I still see this a simple matter of violating KISS to introduce a layer of encryption.
> The question is, to which end? Sure, an attacker might see the encrypted
> file and think it's "too difficult" for him to get to the passwords. Another
> might use a certain utility to decrypt the said file. The thing is, to which end are
> we encrypting the data? Just for the sake of making it work like the N other programs?
> I mean, if this doesn't *work*, why even *bother*?

Sorry, but your comments are totally useless here and can't even
really be addressed properly, given their quite ridiculous nature.


Well done on behaving in a gentlemanly manner and winning people over with your in-depth technical arguments.


I think you need to break down the problem into the various threats against these stored secrets.


1) You're worried about some random person who has transient physical access to your logged-in machine.


2) You're worried about some sophisticated actor who has transient physical access to your machine.


3) You're worried about your machine getting stolen, or improper disposal of your hard drive.


4) You're worried about the worst-possible impact of a file-theft bug, perhaps in a browser.


5) You're worried about having used FileZilla on a public terminal.


6) You're worried because multiple users without full trust between one another share the same account.


Feel free to add 7), 8), etc.


Once you start breaking it down, you realize that you're completely shit-out-of-luck in cases 2), 5) and 6); in case 1), the worst attacks comprise of writing to the drive and not reading from it; you're negligent if you're worried about 3) and don't have full-disk encryption; and 4) is actually the most nuanced and interesting threat yet it doesn't seem to be figuring in the reasoning of prior entrants to the thread.


In fact, given the current state of the security industry, I think I have the worst threat yet:


7) You're worried about a large number of bike-shedding lower-tier security researchers posting en-masse to f-d. You're worried that subsequent to this, some less technical security journalists will pick up on it and write a bunch of sensationalist news articles covering what is essentially a minor issue.




The opening e-mail used or quoted phrases such as "critical deficiency", "total lapse" and "quite disturbing". This shows a disappointing misunderstanding of what "critical" really is.


This bug is not being used to break into nuclear reactors in Iran, or to distribute mass malware. It's important to be balanced and realistic whilst discussing security issues.




Cheers
Chris



You
are missing the point of the encryption, and it is not my job to
convince you, and any further comments with anyone other than the
developer are useless.



> > There is no question here. There is no discussion. It should be done,
> > and if it is not, password saving should be stopped in FileZilla or an
> > alternative program should be sought. It's that simple.
>
> Great. If it's so simple that it can be done in under 10 mins, go complain
> to them.

This email thread *is* a direct complaint to them, after bugs have
been closed for years. I didn't start this thread. Do you even
understand what is going on here? Your emails suggest you do not.


> Cheers,

> Chris.


--
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."




_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: Filezilla's silent caching of user's credentials [ In reply to ]
On Thu, Oct 14, 2010 at 7:20 PM, Christian Sciberras <uuf6429@gmail.com> wrote:
>> exactly how wrong their thought processes are. My post was meant to
>> encourage the reader to actually try and re-evalue his position own
>> his own and try a little bit of self-education on the matter.
>
> That's some nice encouragement. Kind of reminds me of Windows XP's
> connection troubleshooter;
>
> "Please visit the interwebz and we'll help you connect to the internet."
>
> Just because you signed up on FD and have a fancy blog doesn't mean you're
> any better.

I accept this point. I will not engage further as I'm adding to the
uselessness. I will leave you with one thought. Shouldn't the default
be encrypt?

--
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

1 2  View All