Message 24738

Message id


On Thu, 10 Mar 2016 00:52:27 +0100
Mathias Behrle <> wrote:

> > > ad2)
> > > The logs could fill up much more quickly than the database table
> > > in every day scenarios. While this is true, the server itself
> > > comes with no logging enabled and logging has to be enabled by
> > > the user/admin. The attack surface of a vanilla trytond instance
> > > should be non-existent.
> > >     
> > In 24x7 scenarios, standby databases / log shipping, and when
> > point-in-time recovery is needed, the archive log would/should be
> > active.   
> I was originally referring in this paragraph to the logging of
> trytond.

Trytond logging generation in this context will be affected, and they
could get quite large. But it can be controlled (log rotation, filter
type of events, ...), in a similar way that other OS system services
logs are managed. So I don't much of a problem here.

I see a larger problem with the high rate of DB transaction logs
generation, since they are write and delete operations.

> > Currently, if transaction log archiving is active, all the write /
> > delete operations involved in this vulnerability would generate a
> > very large amount of space, disk IO, network resources, etc ..  
> There is also the impact on memory, because logins go into the cache.
> This impact should be mitigated by the planned size constraint for
> logins. 

We found out that putting the server under stress with the exploit, led
to many concurrency errors when resetting the cache[1]

After applying the patch, we could not reproduce the error.

> > To minimize the impact, I propose not using at all a DB table for
> > storing this type of ephemeral information.  
> I would agree on that. Not sure if it could be sufficient to only use
> the cache, since AFAIS LoginAttempt is primarily used by User to get
> the count of login attempts. As I am also not a friend of the
> increasing delay it seems for me sufficient to know if a login was
> already tried (i.e. is in the cache) and then set a fixed delay (in
> case the login attempt was unsuccessful in the first place), thus
> avoiding completely the use of a database object.

Actually, that's what the patch does:

* Removes write operations to the DB table (LoginAttempt methods).
  This fixes the main vulnerability.

* Sets a default timeout for *any* invalid login attempt, minimizing
  brute force attacks.

The default timeout (3 seconds) can be modified in the future Tryton
version with a configuration parameter (failed_login_timeout). If you
prefer a more conservative default value (4 or 5 seconds), we can raise

> > > - (D)DOS is a general problem of each web application    
> > 
> > I don't consider this vulnerability related to the web application
> > server DoS, in the general connection / socket exhaustion. In this
> > vulnerability the highest level of impact is generated at DB /
> > IO subsystem, *not* at Tryton application server. 
> > 
> > In fact, just about 20 processes to generate a very high load that
> > would make the system unsuable (even without log archive mode). So
> > is not really the amount of connections the real problem for this
> > vulnerability, although it's always a contributing factor.  
> Well, so it is still the point to configure the database system to
> only accept the number of connections it can handle. How should the
> system handle the load of heavily used connections if it can not
> handle the same number of login requests?

Yes. In fact, that is part what happens in this case.  The PoC exploit
consumes a lot of resources (IO, process, memory...) leading
to contention and finally, reaching a saturation point, where accepting
extra available db connections will actually make things worse [2]. 

Date User Action Args
2016-03-10 19:51:00meanmiciosetrecipients: + yangoon
2016-03-10 19:51:00meanmiciolinkissue5375 messages
2016-03-10 19:50:59meanmiciocreate

Showing 10 items. Show all history (warning: this could be VERY long)