Closed Bug 546308 Opened 15 years ago Closed 15 years ago

<keygen> dos & stability issues.

Categories

(Firefox :: Security, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 469565

People

(Reporter: info, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 Hello, Besides the obvious denial of service the attached proof of concept produces, I also found some stability issues regarding the <keygen> HTML tag when using the RSA KEYTYPE, which involves heavy computation and notable resource depletion. It occured to me that when this tag is used in combination with a special script I produced, it is possible to clog up the Key3.db residing in the users profile folder. Several tests concluded that Key3.db will grow enormously when using the provided example. It grew from a few KB's to 1.44MB in matter of minutes. Since this Key.db is used for login credentials as well (?) it has some noticeable impact on further browsing and interacting with websites. Memory consumption also continues to level above 100 Megs after running and restarting FireFox. (Your mileage may vary here) i. Clogging up the Key3.db doesn't seem critical yet, but it's undesirable since editing the file or restoring it isn't always possible for the casual users without the risk of legitimate data already stored in tat particular file. ii. The denial of service is obvious because it requires a lot of CPU cycles to compute cryptographic keys. There might be other risks involved here as well, beyond the scope of what I found yet to be determined. iii. I do not have any information if there is a certain limit to the Key3.db, nor do I know if there is a limit on storing a limited number of keys per site (desirable?) These missing variables might change the proof of concept. Reproducible: Always Steps to Reproduce: Copy and paste this into a HTML file and run it: http://pastie.org/825451 OR: Visit a live PoC: http://www.scarletred.nl/cryptokombat.html (watch out since it CAN damage your profile folder's Key.db) Expected Results: It sounds reasonable to limit the actual keys stored per site, like the cookie scheme for example where there is a limit on the amount of cookies stored on a computer.
I just found this other bug: https://bugzilla.mozilla.org/show_bug.cgi?id=469565 It didn't show up on my first search before posting though? Actually strikingly similar, but with a few differences in approach. I guess as Linus said, Many Eyes Make All Bugs Shallow. I think we can mark it as duplicate?
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.