Steffen Nurpmeso <[email protected]> wrote: e> Theo de Raadt wrote in > <[email protected]>: > |I was reading some openssl source code, in particular the x86 assembly > |language files (which accelerate some crypto operations), and I find > |many cases where data tables are intentionally inserted into text (code) > |segments, and those tables include the byte value 0xC3. > | > |By intentional, I mean there's a comment, don't let me judge the tone \ > |of it: > | > |&set_label("AES_Td",64); # Yes! I keep it in the code segment! > > This could get you going with only TEXT and stack/BSS! > Boost cache hotness and reduce memory wastage!! > It was a real thing -- i am in full sympathy to the neat idea (a > common thing at some time i lifed through).
Spectre came about due to processors prefetching so aggressively, and on any processor less than 10 years old those tables are nearly or just as hot if you place it in rodata as text. That's old school garbage. Why don't we turn all the mitigations off as soon as you link -lcrypto. That is the kind of excuse making being made. > |Far be it from me to suggest that the security experts over there in > |OpenSSL land are unaware of modern exploitation methods! Very far from > |that, very very far. > > I would presume the above code to be very old. There were times > when that project was lingering "on empty", and speeding assembler > optimizations was major traffic on their ML. I don't care if code is old. I only care if it has risks or bugs today. I've seen old code which was correct, and I've seen old code which was fixed over and over, and I've seen new code that is correct from the start also. I don't care about the age, I care about the attempt at correctness. It is all anyone cares about. As "on empty" back old times, that doesn't matter either. It has been coming on a decade. They are full of money now. This #1 role of this code is to be better. Speed is important but secondary. Where is the better? Not being reactive to new information is not proactive by definition. But return oriented programming and x86 instruction polymorphism has been known and presented at talks since the days of anchords being added to pf. Around 2004 timeframe. This is a bit different than polymorphism (which is interpreting variable-sized instruction sequences at alternative offsets), but it is worse (data tables placed into code without giving a shit about the bytes in the data tables having meaning as instructions) because it is intentional introduction of alternative risk into code, which amusingly shows attempts to resolve spectre issues but not *ROP ATTACK METHODOLOGY which is older* Nearly 20 years behind the time is inexecusible, but they probably have nice dinners with their newfound money talking about quic. > On most operating systems code segment is readable anyway. > I would presume adjusting execution pointer to such a byte would > result in abortion because often compilations use > stack-protector-strong and such (sigh). (..Yes, yes..) What. The third person to reply to me who doesn't know what return oriented programming is. The stack protector can't help you. If you don't understand return oriented programming that's precisely the kind of thing you would say. There really is no need to demonstrate being uneducated.
