The perlpod(1) to mdoc(7) conversion finally completed, i'm currently documenting minor odds and ends from LibreSSL libcrypto that are public but undocumented in OpenSSL. I'm no longer sure it isn't torture if you do it to yourself, and definitely some folks at OpenSSL are guilty of abetting.
Take the simple, specific function EC_KEY_print(3), for example. Here is the call tree it descends into internally (simplified for brevity):
EC_KEY_print() in ec/eck_prn.c calls:
1. EVP_PKEY_new() in evp/p_lib.c - doing malloc(3) and initialization
2. EVP_PKEY_set1_EC_KEY() in evp/p_lib.c to embed the specific EC_KEY object into the newly allocated generic EVP_PKEY object - internally, this calls a specific macro that expands to a call to a generic function called with a fixed specific type argument, ultimately mostly assigning a pointer; but for giggles, it also does reference counting.
3. EVP_PKEY_print_private() in evp/p_lib.c - which uses the function table in ec/ec_ameth.c to dispatch to:
3.1. eckey_priv_print() in ec/ec_ameth.c - which calls nothing but:
3.1.1. do_EC_KEY_print() in ec/ec_ameth.c - which does the actual work of calling ASN1_bn_print() etc.
4. EVP_PKEY_free() in evp/p_lib.c - to clean up the temporary EVP_PKEY again.
So why the hell do you embed a specific object into a temporary generic object and extract exactly the same object again just to print its content? Why doesn't EC_KEY_print() call do_EC_KEY_print() directly, heck, why are these two not one and the same function in the first place? To boost the opportunity for bugs or what? This is not even abstraction because the bloody user interface function is already algorithm-specific. The pseudo-abstraction is purely internal.
Probably to allow alternative elliptic curve implementations, i guess. Yeah. Totally great idea. Everybody and their grandma should have the chance to write right their own low-level elliptic curve implementations and plug them in at run-time. We totally need code allowing that in each and every web browser, right?
Right. It is torture even if you do it to yourself. And OpenSSL is aiding and abetting a lot.
In case you still don't get it. If there is a bug in your browser allowing write access to arbitrary heap memory, a remote attacker from one malicious site you have been browsing may have succeeded in switching the function pointers implementing your low-level cryptographic primitives to something else under your ass, so when those pointers get used the next time you need them for online banking, god knows what code may get called in the guts of OpenSSL. Even W^X doesn't help here 'cause those function pointers are data, not executable memory...
Boy, how i feel secure now. The architecture of this code may be adequate for a maximum flexibility research project that doesn't need any kind of security, intended to easily play around with each and every crazy idea. The design is nowhere near sane for any production environment. Nobody should be using this shit in production. Yet, where is the alternative? Even LibreSSL can only help so much because the insanity is already in the user interface design, not just in the implementation, and interface compatibility is certainly needed...
Take the simple, specific function EC_KEY_print(3), for example. Here is the call tree it descends into internally (simplified for brevity):
EC_KEY_print() in ec/eck_prn.c calls:
1. EVP_PKEY_new() in evp/p_lib.c - doing malloc(3) and initialization
2. EVP_PKEY_set1_EC_KEY() in evp/p_lib.c to embed the specific EC_KEY object into the newly allocated generic EVP_PKEY object - internally, this calls a specific macro that expands to a call to a generic function called with a fixed specific type argument, ultimately mostly assigning a pointer; but for giggles, it also does reference counting.
3. EVP_PKEY_print_private() in evp/p_lib.c - which uses the function table in ec/ec_ameth.c to dispatch to:
3.1. eckey_priv_print() in ec/ec_ameth.c - which calls nothing but:
3.1.1. do_EC_KEY_print() in ec/ec_ameth.c - which does the actual work of calling ASN1_bn_print() etc.
4. EVP_PKEY_free() in evp/p_lib.c - to clean up the temporary EVP_PKEY again.
So why the hell do you embed a specific object into a temporary generic object and extract exactly the same object again just to print its content? Why doesn't EC_KEY_print() call do_EC_KEY_print() directly, heck, why are these two not one and the same function in the first place? To boost the opportunity for bugs or what? This is not even abstraction because the bloody user interface function is already algorithm-specific. The pseudo-abstraction is purely internal.
Probably to allow alternative elliptic curve implementations, i guess. Yeah. Totally great idea. Everybody and their grandma should have the chance to write right their own low-level elliptic curve implementations and plug them in at run-time. We totally need code allowing that in each and every web browser, right?
Right. It is torture even if you do it to yourself. And OpenSSL is aiding and abetting a lot.
In case you still don't get it. If there is a bug in your browser allowing write access to arbitrary heap memory, a remote attacker from one malicious site you have been browsing may have succeeded in switching the function pointers implementing your low-level cryptographic primitives to something else under your ass, so when those pointers get used the next time you need them for online banking, god knows what code may get called in the guts of OpenSSL. Even W^X doesn't help here 'cause those function pointers are data, not executable memory...
Boy, how i feel secure now. The architecture of this code may be adequate for a maximum flexibility research project that doesn't need any kind of security, intended to easily play around with each and every crazy idea. The design is nowhere near sane for any production environment. Nobody should be using this shit in production. Yet, where is the alternative? Even LibreSSL can only help so much because the insanity is already in the user interface design, not just in the implementation, and interface compatibility is certainly needed...
Add a comment...