OpenSSL Security Advisory [7th February 2023]
1–10 of 54 posts
Re: OpenSSL Security Advisory [7th February 2023]
#2Are these dates correct?
An initial report of a possible timing side channel was made on 14th July 2020
by Hubert Kario (Red Hat). A refined report identifying a specific timing side
channel was made on 15th July 2022 by Hubert Kario.
The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario.
EDIT: By interesting I just mean "an amusing coincidence" or "possibly a typo", nothing weird.
Re: OpenSSL Security Advisory [7th February 2023]
#3Are these dates correct? An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. If so, it's interesting that it took exactly 2 years and 1 day for the refined report. EDIT: By interesting I just…
Why is that interesting?
Re: OpenSSL Security Advisory [7th February 2023]
#4Are these dates correct? An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. If so, it's interesting that it took exactly 2 years and 1 day for the refined report. EDIT: By interesting I just…
Why is that interesting?
Is taking 2 years to address a vulnerability normal?
Re: OpenSSL Security Advisory [7th February 2023]
#5Earlier quoted context omitted.
Why is that interesting?
Is taking 2 years to address a vulnerability normal?
Maybe in this case! You can look at P1v15 RSA and assume that there might be some kind of behavior oracle, which is definitely not the same thing as demonstrating that there is a viable oracle. A problem with P1v15 in general is that you have to mitigate these kinds of covert channels directly.
But I assume the comment above was suggesting there was something more interesting than the magnitude of the lag.
Re: OpenSSL Security Advisory [7th February 2023]
#6Re: OpenSSL Security Advisory [7th February 2023]
#7Are these dates correct? An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. If so, it's interesting that it took exactly 2 years and 1 day for the refined report. EDIT: By interesting I just…
Why is that interesting?
2 year was frequently the length of ssl certificates (they’ve since dropped to 1 year)
Or maybe it’s a coincidence.
Re: OpenSSL Security Advisory [7th February 2023]
#8Are these dates correct? An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. If so, it's interesting that it took exactly 2 years and 1 day for the refined report. EDIT: By interesting I just…
Why is that interesting?
It's interesting because it looks like it could be a typo on the year (2022 -> 2020), if the date turns out to not be correct. That's all.
Re: OpenSSL Security Advisory [7th February 2023]
#9A few more CVEs and we're at OpenSSL 1.1.1z, followed by v1.1.1.za, and it is going to break some package manager that in a certain locale orders versions as 1.1.1.za > 1.1.1z, and its users will be stuck on a vulnerable version.
Re: OpenSSL Security Advisory [7th February 2023]
#10Earlier quoted context omitted.
Why is that interesting?
Is taking 2 years to address a vulnerability normal?
“I think there may be a bug but I can’t reproduce it” is quite common
I just managed to repot use a bug in a vision system that I saw in august. Finally managed to reproduce it mostly last week.