Message 24720

Author
yangoon
Date
2016-03-10.00:52:11
Message id
24720

Content

* Luis Falcon: " [issue5375] Server vulnerability in get_login" (Wed, 09 Mar
  2016 18:12:26 +0100):

> Luis Falcon <falcon@gnu.org> added the comment:
> 
> Hi Mathias !
> 
> On Wed, 09 Mar 2016 14:36:06 +0100
> Mathias Behrle <issue_tracker@tryton.org> wrote:
> 
> > Mathias Behrle <mbehrle@m9s.biz> added the comment:
> > 
> > Since there were some summaries posted, but none was really
> > exhaustive, I am proposing this one to get more structure into the
> > discussion. Probably it would be an advantage to discuss some points
> > in the public once this issue will be disclosed.  
> 
> Thanks !
> 
> > 
> > Topic 1: Subject of this issue: Server vulnerability in get_login
> > 
> > It was claimed, that the server is vulnerable by running multiple
> > login attempts. As a consequence of multiple login attempts it was
> > assumed that 1) the login table could fill up and the database could
> > run out of available space,
> > 2) the logs could fill up and the (Tryton) server could run out of
> > available space,
> > 3) the server could undergo heavy load as far as being unresponsive
> > under (D)DOS.
> > 
> > ad 1)
> > The table res_user_login_attempt with respect to field sizes mainly
> > consists of the field "login character varying". The maximal length of
> > character varying in e.g. postgresql is assumed to be ca. 1GB [1]. So
> > indeed here could evtl. be an attack vector to make the database
> > unresponsive given the size of the login is not limited by other
> > measures. The impact of this issue should be clarified in a separate
> > discussion. While it could be that the database goes unresponsive,
> > there will be no leakage of data or information from the side of the
> > server.
> >   
> 
> Agree 
> 
> > 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.

> 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.
 
> 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.

> If at the end we will opt to use a db object to store volatile info
> such as in LoginAttempt, then I propose using an UNLOGGED table, that
> would not use WAL / transaction logs, minimizing the impact. 
> Let me know your thoughts.
> 
> > ad3)
> > The server could be subject to (D)DOS by exhausting the connection
> > pool with running multiple connections. IIRC this issue was already
> > discussed in the early times of the project (especially when
> > comparing to the login attempt delay, see below) and is a long known
> > 'secret'. It was shown that the connection limit of the server is
> > mainly defined by the connection limit of the database. Depending on
> > the system ressources and the configuration of the database backend
> > the system could indeed be subject to DOS attacks. While this is true
> > it was also noted, that the nature of those attacks can/should better
> > be handled on OS level than on application level.
> >   
> 
> Agree. And that is a separate issue than the vulnerability I presented.
> 
> In the context of this vulnerability, when I talk about exhausting the
> resources, I am not referring to the connection pool. I am aiming to the
> to IO / DB / CPU resources. In fact, the high system load and
> concurrency errors Sebas was referring[1] were reproduced using the
> PoC exploit. 
> 
> > Further discussion of this topic is needed
> > - if and what something could evtl. be done on the server side (e.g.
> > [2][3])
> > - how a trytond installation could be hardened with the use of
> > 3rd-party tools like iptables, fail2ban etc. (best practices)
> > 
> > Personal opinion:
> > There are for sure different opinions how and if the (D)DOS attack
> > surface should be classified as vulnerability. With reference to this
> > issue I am inclined to rather classify it as non-security, because
> > - there is no data leak from the application  
> 
> True
> 
> > - (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?

> > - finally the issue is well known since a long time
> >   
> 
> True for the classical DoS on web application servers.
> 
> > 
> > Topic 2: Login delay
> > While there is practically no login delay for new sessions, there is
> > a rapidly increasing delay for login attempts in the same session.
> > It was shown, that the attack surface via new connections is much
> > bigger than the danger to break in via repeated login trials. It was
> > suggested to reduce the 'punishment' caused by the waiting time until
> > a new login attempt can be made. Given that the attack surface of
> > this repeated login is relatively low compared to the surface exposed
> > by new connections, considerable lower (and/or) configurable waiting
> > delays were proposed. Thus the current delay increase could be too
> > conservative.  
> 
> Agree
> 
> > 
> > I propose to discuss this topic separately. As it is not relevant to
> > the original topic, it doesn't add to the security relevance of this
> > very issue (Server vulnerability in get_login).  
> 
> Agree
> 
> > 
> > 
> > Topic 3: Password security
> > There were added several concerns relating to password security.
> > Especially the security of the admin password was put in question.
> > 
> > Currently trytond comes with no password configured at all. It is at
> > the discretion of the user/admin to impose/configure those according
> > to the guidelines of the enterprise.
> > 
> > There seems currently no immediate danger caused by trytond. Again I
> > propose to discuss the need of additional security measurements like
> > expiry, length, etc. separately if needed, at least this topic
> > doesn't add to the security relevance of this very issue.
> >   
> 
> Agree. It's a very important issue, but not related to this
> vulnerability. Happy to discuss and collaborate in another thread.
> 
> > Hopefully I didn't miss any valuable points, please add others if
> > adequate.
> >   
> 
> Thanks a lot for shedding light and constructive feedback !
> 
> I propose keep up collecting and discussing the suggestions / proposals
> directly related to the vulnerability. 
> 
> As with any constructive discussion, the outcome will be a more robust
> Tryton server and community.
> 
> All the best,
> Luis
> 
> 1.- https://bugs.tryton.org/msg24652
History
Date User Action Args
2016-03-10 00:52:27yangoonsetmessageid: <1457567547.56.0.163699123445.issue5375@tryton.org>
2016-03-10 00:52:27yangoonsetrecipients: + ced, bch, nicoe, sharkcz, meanmicio, smarro, pokoli, ajacoutot
2016-03-10 00:52:27yangoonlinkissue5375 messages
2016-03-10 00:52:11yangooncreate

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