3 ms·

Based on linked article I disagree, based on further references prev article (https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerability-severity-levels/

Based on linked article I disagree, based on further references prev article (https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerability-severity-levels/ https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerab...) I could kinda agree but only due to my lack of understanding the real scope of consequences. It's disaster when system handling user data is showing data for another user and this is how I understand effects of https://curl.se/docs/CVE-2023-27536.html https://curl.se/docs/CVE-2023-27536.html manifesting in real world. It was wrong even before privacy regulations were invented. With prev issue (https://curl.se/docs/CVE-2022-42915.html https://curl.se/docs/CVE-2022-42915.html) it seems more sophisticated to take advantage of and probably requires planting something in memory by other means, but I'm not "malware specialist", I don't know assembly well enough to judge it myself. It's all good that some of these things can be found by libcurl authors/maintainers themselves. I'd love to see directly in CVE registries that source of CVE was internal to the project without need to lookup the reporters. If there is some feature even with lowest usage among all of them it is still a feature, and as author of library you don't have control about usage of your library. I think the GSS delegation bug well deserved initial score. From library user side as developer I'd love to see it as critical and then write report about false positive based on library usage to pass CI checks on my side. And it's not blame for you to have race conditions, it's praise for not having them anymore.

dfox 3y ago
> It's disaster when system handling user data is showing data for another user and this is how I understand effects of https://curl.se/docs/CVE-2023-27536.html https://curl.se/docs/CVE-2023-27536.html manifesting in real world. It was wrong even before privacy regulations were invented. It exposes data to user who in the first place had a right to see them (it very much evokes the "airtight hatchway", although strictly speaking it is not the same thing). Also the whole combination is incredibly niche in the first place and it is hard to see why the client code would ever want to establish second connection to the same server without GSSAPI. In essence it is minor implementation oversight that has no practical consequences and probably the only reason why it even has a CVE number is that there is GSSAPI involved with that.
- waterCalendar 3y ago
  > It exposes data to user who in the first place had a right to see them I would be surprised if it is the only scenario. I've seen systems which rely on passing requests here and there with some common account auth wrapping communication to further services in very various ways and for variety of reasons. Some of the reasons to use single authentication mechanisms on gateway levels are laughable or at least cannot be treated seriously and should end up in redesign yet too many dev teams agrees on such shortcuts as their client says they don't have money for something like proper solution. And again, minor implementation detail is not a valid argument. It is problem of people who judge another project based on unpatched high severity lib version with bug in unused feature. Companies coming seriously to security have security teams or approvals responsible for assessing impact of severe bugs. It's the other ones in huge numbers demanding smaller severity scores. For me these are like alcohol advocacy during pregnancy. Maybe I'm missing something, but looking at concept explanation here: https://docs.oracle.com/cd/E19455-01/806-3814/overview-77/index.html https://docs.oracle.com/cd/E19455-01/806-3814/overview-77/in... I would never assume both connections can be used safely in general case, yet it can be ok if business logic ok with that and is limited to process single user requests with vulnerable libcurl version.
- tremon 3y ago
  establish second connection to the same server without GSSAPI As I understood the description, it's not even that: you would need to establish two connections, both with GSSAPI and using the same username, but with different credential scoping options (the text says with or without credential delegation, but GSSAPI has other options besides delegation and it's not clear to me if that's just an example). In such a case, the client has no control over which connection would actually be used.

dfox 3y ago

> It's disaster when system handling user data is showing data for another user and this is how I understand effects of https://curl.se/docs/CVE-2023-27536.html https://curl.se/docs/CVE-2023-27536.html manifesting in real world. It was wrong even before privacy regulations were invented. It exposes data to user who in the first place had a right to see them (it very much evokes the "airtight hatchway", although strictly speaking it is not the same thing). Also the whole combination is incredibly niche in the first place and it is hard to see why the client code would ever want to establish second connection to the same server without GSSAPI. In essence it is minor implementation oversight that has no practical consequences and probably the only reason why it even has a CVE number is that there is GSSAPI involved with that.

waterCalendar 3y ago
> It exposes data to user who in the first place had a right to see them I would be surprised if it is the only scenario. I've seen systems which rely on passing requests here and there with some common account auth wrapping communication to further services in very various ways and for variety of reasons. Some of the reasons to use single authentication mechanisms on gateway levels are laughable or at least cannot be treated seriously and should end up in redesign yet too many dev teams agrees on such shortcuts as their client says they don't have money for something like proper solution. And again, minor implementation detail is not a valid argument. It is problem of people who judge another project based on unpatched high severity lib version with bug in unused feature. Companies coming seriously to security have security teams or approvals responsible for assessing impact of severe bugs. It's the other ones in huge numbers demanding smaller severity scores. For me these are like alcohol advocacy during pregnancy. Maybe I'm missing something, but looking at concept explanation here: https://docs.oracle.com/cd/E19455-01/806-3814/overview-77/index.html https://docs.oracle.com/cd/E19455-01/806-3814/overview-77/in... I would never assume both connections can be used safely in general case, yet it can be ok if business logic ok with that and is limited to process single user requests with vulnerable libcurl version.
tremon 3y ago
establish second connection to the same server without GSSAPI As I understood the description, it's not even that: you would need to establish two connections, both with GSSAPI and using the same username, but with different credential scoping options (the text says with or without credential delegation, but GSSAPI has other options besides delegation and it's not clear to me if that's just an example). In such a case, the client has no control over which connection would actually be used.