forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [proposal] Doco
Date Mon, 27 Oct 2003 14:05:33 GMT

On Sunday, Oct 26, 2003, at 23:33 Europe/Rome, Noel J. Bergman wrote:

>> He's not questioning whether it's encrypted.  His point is, doco sends
>> an email to an address, and you respond.  It gives very little 
>> control,
>> even if there is a compromise.
>
> AIUI, the proposed solution would allow "anyone" to edit content, and
> contribute it as a "patch".  Content could include defacements, 
> changes to
> .htaccess, and CGI scripts.

nah, dude, look: doco has a very precise editing access point. You can 
*ONLY* modify xml content. So, changes to .htaccess, CGI scripts, 
servlet upload, sql injection, cross-site-scripting, and you next 
favorite attack will NOT work because the system prevents it by design 
[not saying it cannot happen, but if it does it's a bug, not a faulty 
design]

> So long as we can maintain oversight, this is
> OK.  But if someone can spoof the oversight, then I would be concerned.

I would *NEVER* propose a system where the users can inject an 
.htaccess file, even thru approuval. One single oversight mistake and 
infrastructure@ shuts us down in half a second (if they ever allow the 
system to run, and I personally wouldn't).

The unique and only security concern here is defacement.

> I am not trying to shoot this idea down.  I think it is a good thing 
> to do,
> and will really help.

I really appreciate your concerns and, please, keep in mind that I read 
and send my email via SSH tunnels, so I *KNOW* what goes on my tcp/ip 
stack [also, IMAP over compressed SSH is orders of magnitude faster 
when you sit in italy and your imap server is in london! ;-)]

Anyway, here is a potential attack:

Doco sends email to james (localhost).
James multiplexes the email to the moderators (vanilla SMTP)
the attacker sniffs the continuation-ID
replies with the sniffed continuation-ID
James calls Doco and restarts the workflow
Doco sends back email logging the approuval

Potential sniffing places are:
1) right after the doco box (FYI, moof is located at Apple, nagoya at 
Sun)
2) right before the mail server of the moderator or by people who have 
enough priviledges on the moderator mail server.

The above attack is plausible and it would allow the attacker to get 
stuff in the repository, but *NOT* to prevent other moderators to see 
that this content has been approuved. [that would require substantial 
forging of the output stream... possible as well, but much harder to 
achieve]

The other moderators would see it as a mistake and get there fixing it 
before the next site update.

Keep in mind that there are *two* 12 hour stages, so, even if the 
attacker attacks right before the first staging (the forrestbot 
execution), the moderators have 12 hours to understand that something 
was wrong and login to fix things before the other stage (rsync from 
minotaur) takes place.

I think you proposed to use SMTP over SSL for mail relay, that would 
reduce the ability of somebody to prevent sniffing the continuation-ID 
and provide that attack.

I do agree it would help reducing the risk, but would all moderator's 
SMTP server support that? [keep in mind that a sniffer could understand 
the list of moderators just by watching email outgoing traffic, even if 
encrypted, by comparing with the list of users on the mail lists]

Another solution is to force moderators to digitally sign their email, 
but this would require a much more intrusive setup.

At the end, I don't think anybody would do such an attack since:

  1) it can't be proved that it was an attack (we can always say it was 
a mistake of the moderators), so you can't go around feeling proud of 
it or impressing friends of the cracker scene [ego is probably 99% of 
the reasons to deface a web site]

  2) the attacker cannot stop others from keeping oversight on what was 
approuved (doco will send email *after* the moderation to keep 
oversight of everthing that happened)

  3) if we use the lazy consensus moderation method (require 3 accept 
and no reject), the attack is just as easy, but the chance that the 
moderator that the attacker would *fake* is offline for 24 hours and 
cannot yell "WTF, I didn't do it" at the moderator list is much less

So, adding SSL relay wouldn't hurt, but wouldn't help much either since 
we can't force moderators to have a mail server that accepts that kind 
of relay (don't even know if mine does!)

at least, this is MHO.

--
Stefano.


Mime
View raw message