Hi Nelson, > Yes, there are. I found this issue by hitting it in the real world, > even that sparkled the investigation. It reproduces on Mandriva > 2010.1, Ubuntu 10.04 and Chromium OS distributions.
Can you submit the testcase, or point us to the software that reproduces it? > That's correct. This code does not process attributes. It keeps the > original call (which does the processing) and fixes the public > exponent, if appropriate. No other behavior should change other than > that. The only attribute targeted here is the public exponent (all > others are responsibility of the same players as before the patch.) > > > Can you be more specific to what issue you're seeing here? > > > > Sure. The idea is the following: > > > 1) we need to check and return buffer too small upfront, because the > underlying functions will return generic errors if the buffer is > actually too small and there is no way from this level (and above) to > tell the difference. the only reason for the first check is to return > a more appropriate, and actionable, error code to the caller I'm not seeing which generic errors you're referring to, can you give file/line #? Thanks, Kent > 2) if you have a buffer large enough for the exponent, we allow the > call to proceed. then: > > > 3) when it returns, we check if the exponent was filled by the > underlying layers. we noticed that 2 cases can happen: > a) the exponent is filled by the callee (which happened if we > imported the private key into the TPM) and > b) the exponent is not filled (which happened if we generated the > private key inside the TPM > > In (3a) I assume that happens because when I import the key it is > being stored "as is" and we pass the exponent as part of the private > key structure. Anyway, the if() check is prevent overwriting something > the callee already filled, and also does not make sense to copy over > the same data, and per the existing checks in place ensure the number > has to be 65537. > > > > > > > > -Klaus > > > -- > Klaus Heinrich Kiwi | [email protected] | > http://blog.klauskiwi.com > Open Source Security blog : http://www.ratliff.net/blog > IBM Linux Technology Center : http://www.ibm.com/linux/ltc > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ Opencryptoki-tech mailing > list [email protected] > https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Opencryptoki-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech
