Re: Issues regarding ruby-rack/CVE-2019-16782

Hi Ola, On Tue, 28 Apr, 2020, 3:06 PM Ola Lundqvist, wrote: > I think the Debian Security team usually wants to judge that on their > own. You can write a note about it in the CVE entry. > So before the regular security team has said anything we should not do > that. > Sure thing. Given that

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi I think the Debian Security team usually wants to judge that on their own. You can write a note about it in the CVE entry. So before the regular security team has said anything we should not do that. // Ola On Tue, 28 Apr 2020 at 10:26, Utkarsh Gupta wrote: > > Hi all, > > On Fri, Apr 24,

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi all, On Fri, Apr 24, 2020 at 3:09 AM Utkarsh Gupta wrote: > Thank you for this. I've started to think on the same lines. > During this weekend, I'll take a quick look over what other > distributions are doing for this. I took a look and couldn't find anything. Interestingly, the advisory[1]

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi I think a no-dsa (ignored) would be good in this case. Ignored because we have been quite detailed in the analysis and the upstream fix causes a regression. // Ola On Thu, 23 Apr 2020 at 23:40, Utkarsh Gupta wrote: > > Hi Brian, > > On Fri, Apr 24, 2020 at 2:49 AM Brian May wrote: > > For

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi Brian, On Fri, Apr 24, 2020 at 2:49 AM Brian May wrote: > For reference I filled a similar bug against Django > and they > responded with: > > > After consideration, the Django Security Team conclude that this is not > > a practical

Re: Issues regarding ruby-rack/CVE-2019-16782

Utkarsh Gupta writes: > Please don't yet patch CVE-2019-16782 for Buster, Stretch, Jessie, et al. > This security update induces a regression, resulting in some issues in > using the library. > Also, there's a slight possibility of this patch inducing a backdoor on > it's own. > > The issues

Re: Issues regarding ruby-rack/CVE-2019-16782

Ola Lundqvist writes: > I have looked into this some but I have not been able to determine how long > the session ids were before the fix. Do anyone have that information? > Based on that we can rather easily determine how long time a timing attack > would take. My guess is a really long time.

Re: Issues regarding ruby-rack/CVE-2019-16782

The comment about that one is safe for anyone to have and the private cannot be leaked is really strange. It is trivial to generate the private one, just as you write. // Ola On Tue, 10 Mar 2020 at 07:38, Brian May wrote: > Ola Lundqvist writes: > > > I think the attacker needs to be very

Re: Issues regarding ruby-rack/CVE-2019-16782

Ola Lundqvist writes: > I think the attacker needs to be very close, or at least on a connection to > the server with a very predictable timing making a live server exploit > difficult from a distance. Potentially possible. Yes, very likely. Unless the database is loaded, but that too could be

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi Now I have been thinking about this a little more. I have now understood that there is one attack vector that I had not been thinking of. The session id length and its randomness is an important factor but the timing attack can exploit the database indexing functionality in order to reduce the

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi Precisely. This is why I was asking about the length of the session id used. With the length we can estimate how many times an attacker my try to find all possible values. If this is small enough (and the attacker is close enough) it can be exploited. But if the session key is really large,

Re: Issues regarding ruby-rack/CVE-2019-16782

Ola Lundqvist writes: > So regarding your throught about why Rack has this and not others. Well I > think all have the same issue. I think it is a little of a stretch that > this can be used in practice. I mean an attacker must do a broad search of > all possible session identifiers to make use

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi Thank a lot for the explanation. Yes that was a little of an unfortunate naming. In any case it does not matter so much. Some thoughts. 1) It should be possible to change all entries in the session database from the session id (public_id) to the hashed variant to retain all sessions. This

Re: Issues regarding ruby-rack/CVE-2019-16782

Ola Lundqvist writes: > I would have understood the upstream argument if the public key is a hash > of the private one. If it is the other way around (as you describe it) I do > not see any point. > That would even be a new CVE, because that is a security issue, really. > > I think it should

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi I would have understood the upstream argument if the public key is a hash of the private one. If it is the other way around (as you describe it) I do not see any point. That would even be a new CVE, because that is a security issue, really. I think it should return the public key and the

Re: Issues regarding ruby-rack/CVE-2019-16782

Ola Lundqvist writes: > Interesting. I think the upstream solution to search first for private id > and then for public id is good enough for Debian stable releases. > It should be extremely difficult (unless the computer is really slow) to > calculate the timing for the public id part since

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi Brian Interesting. I think the upstream solution to search first for private id and then for public id is good enough for Debian stable releases. It should be extremely difficult (unless the computer is really slow) to calculate the timing for the public id part since there are so many other

Re: Issues regarding ruby-rack/CVE-2019-16782

Ola Lundqvist writes: > I have looked into this some but I have not been able to determine how long > the session ids were before the fix. Do anyone have that information? > Based on that we can rather easily determine how long time a timing attack > would take. My guess is a really long time.

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi I have looked into this some but I have not been able to determine how long the session ids were before the fix. Do anyone have that information? Based on that we can rather easily determine how long time a timing attack would take. My guess is a really long time. Best regards // Ola On

Re: Issues regarding ruby-rack/CVE-2019-16782

Utkarsh Gupta writes: > Please don't yet patch CVE-2019-16782 for Buster, Stretch, Jessie, et al. > This security update induces a regression, resulting in some issues in > using the library. > Also, there's a slight possibility of this patch inducing a backdoor on > it's own. > > The issues

Re: Issues regarding ruby-rack/CVE-2019-16782

Hi Utkarsh, > Please don't yet patch CVE-2019-16782 for Buster, Stretch, Jessie, et al. > This security update induces a regression, resulting in some issues in > using the library. I see your note in data/dla-needed.txt but may I suggest "reserving" ruby-rack there to avoid any chance of it