Vous connaissez tous Brad Spengler, expert en sécurité, auteur de grsecurity, auteurs de plusieurs exploits.
Et bien récemment, un article sur LWN a évoqué un nouvel exploit dont il était l'auteur, mais cette fois c'est le délais de correction qui était souligné (près de 9 mois) : http://lwn.net/Articles/404043/
En lisant l'article, on a l'impression qu'il y a eu un raté dans la gestion du rapport de Brad :
Brad says that he first reported this problem in December, 2009, but got no response. More recently, he sent a note to Kees Cook, who posted a partial fix in response.
Mais en fait, dans les commentaires de l'article, on s'aperçoit que ce n'est pas aussi simple.
Greg Kroah-Hartman lui demande
Was this sent to the security contact for the kernel? I just searched
and could not find any notice sent to security@kernel.org from Brad
during that month.
If it was not sent there, where was it sent?
Ce à quoi Brad répond :
The context was I was already working with Ted on the ext4 bug, and since he was being responsive, chose to share some additional vulnerabilities with him.[...]With the general upstream attitude and handling of security bugs, on principle I don't email vendor-sec or security@.
Donc, Brad n'a pas soumis l'exploit à la mailing-liste chargée de la sécurité, et n'en a fait part à Ted Ts'o que parce qu'il le sentait réactif.
Encore pire, l'exploit avait déjà été corrigé dans grsec depuis un moment :
> I've also got two local DoS mm-related bugs to be fixed if you'd like to
> take a look at them. They exist in all 64bit kernels since 2.6.26 or
> so. The first is an easy fix (we've fixed it in grsec for some time),
> but the other one requires some more thinking and decision making (it's
> memory exhaustion that causes a complete lockup of the machine -- and
> the OOM killer is unaware of the memory because it's not
> associated/accounted for by any task).
Donc pour résumer, on a quelqu'un qui :
- rapporte des exploits quand ça lui chante
- ne les rapporte pas aux personnes concernées
- corrige les failles concernées dans dans grsec
Morale de l'histoire :
- Brad en a sûrement d'autre en réserves, qu'il réserve pour plus tard (à la Sergey Bubka)
- suivez les commits grsec, et vous verrez peut-être passer des patchs pour des failles non corrigées dans le noyau vanilla
# il y a pire...
Posté par neologix . En réponse au journal N05 4M15 135 H4CK3R5. Évalué à 7.
Et bien récemment, un article sur LWN a évoqué un nouvel exploit dont il était l'auteur, mais cette fois c'est le délais de correction qui était souligné (près de 9 mois) : http://lwn.net/Articles/404043/
En lisant l'article, on a l'impression qu'il y a eu un raté dans la gestion du rapport de Brad :
Brad says that he first reported this problem in December, 2009, but got no response. More recently, he sent a note to Kees Cook, who posted a partial fix in response.
Mais en fait, dans les commentaires de l'article, on s'aperçoit que ce n'est pas aussi simple.
Greg Kroah-Hartman lui demande
Was this sent to the security contact for the kernel? I just searched
and could not find any notice sent to security@kernel.org from Brad
during that month.
If it was not sent there, where was it sent?
Ce à quoi Brad répond :
The context was I was already working with Ted on the ext4 bug, and since he was being responsive, chose to share some additional vulnerabilities with him.[...]With the general upstream attitude and handling of security bugs, on principle I don't email vendor-sec or security@.
Donc, Brad n'a pas soumis l'exploit à la mailing-liste chargée de la sécurité, et n'en a fait part à Ted Ts'o que parce qu'il le sentait réactif.
Encore pire, l'exploit avait déjà été corrigé dans grsec depuis un moment :
> I've also got two local DoS mm-related bugs to be fixed if you'd like to
> take a look at them. They exist in all 64bit kernels since 2.6.26 or
> so. The first is an easy fix (we've fixed it in grsec for some time),
> but the other one requires some more thinking and decision making (it's
> memory exhaustion that causes a complete lockup of the machine -- and
> the OOM killer is unaware of the memory because it's not
> associated/accounted for by any task).
Donc pour résumer, on a quelqu'un qui :
- rapporte des exploits quand ça lui chante
- ne les rapporte pas aux personnes concernées
- corrige les failles concernées dans dans grsec
Morale de l'histoire :
- Brad en a sûrement d'autre en réserves, qu'il réserve pour plus tard (à la Sergey Bubka)
- suivez les commits grsec, et vous verrez peut-être passer des patchs pour des failles non corrigées dans le noyau vanilla