I have used SMACK library v4.3.0 in my app for Chat functionality.
My app was sent for security testing and 2 security vulnerabilities were found in SMACK library.
Attached in the detailed report regarding the same.
SMACK vulnerabilities.pdf (119.1 KB)
Thank you, for future reporting and others FYI, please email security@igniterealtime.org with reports like these.
@akrherz Thank you for the response.
Here is another one with high severity.
I’ll also send them all to the above email id.
Smack vulnerability.pdf (98.9 KB)
Regarding
I don’t think SHA-1, as of now, is an issue if used in the context of XEP-0115.
Is there an instance where an insecure Random is used in a security critical context?
This appears to be a report generated by some tool that performs static code analysis. However this always has to be seen in context (which is something that the static analysis performed by the tool can not do).
We know SHA-1 is deprecated years ago right. So shouldn’t it be avoided during implementation of any XEP irrespective of wheather it involves any critical information or not?
Please let me know if this can be fixed.
During implementation? Typically not. Should you not start implementing git just because it’s based on SHA-1? As I wrote, I don’t believe that the usage of SHA-1 in the context of XEP-0115 is an issue at the time of writing this. Of course, when designing a replacement for XEP-0115, then you want to use a newer cryptograhically secure hash algorithm. Unsurprisingly, this is what was done when XEP-0390 (not that XEP-00115 hadn’t already hash agility, but it has other flaws, as stated in the XEP).
Yes, in most contexts it is possible to avoid the usage of SHA-1. Sometimes by using the provided hash agility properties of the context, sometimes by simply disabling the use case of the context, or replacing it with a newer approach.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
