Message 24691

Message id


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.

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
3) the server could undergo heavy load as far as being unresponsive under

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.

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.

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.

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
- (D)DOS is a general problem of each web application
- finally the issue is well known since a long time

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.

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

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.

Hopefully I didn't miss any valuable points, please add others if adequate.

Date User Action Args
2016-03-09 14:36:06yangoonsetmessageid: <>
2016-03-09 14:36:06yangoonsetrecipients: + ced, bch, nicoe, sharkcz, meanmicio, smarro, pokoli, ajacoutot
2016-03-09 14:36:06yangoonlinkissue5375 messages
2016-03-09 14:36:05yangooncreate