He STILL unironically defends static linking

Yeah, because Heartbleed never happened, amirite?

Also, stack smashing and buffer overflows aren't the only issues with using fixed addresses, see side-channel attacks such as TLB prediction (Spectre/Meltdown) and the reasoning for KPTI+KALSR.

And that's only the security aspect, there are a bunch of limitations to static linking in 2018.

>2018
>assuming people on Jow Forums have any idea what they're talking about

OpenSSL doesn't use canaries. KAISER was always going to be a meme, Spencer himself said ASLR was never meant for the kernel due to kernel vs user differences. Side-channel attacks are still possible via collisions even when page table isolation is implemented.

I prefer dynamic linking, but security isn't a factor.

Attached: 1535888042062.gif (282x263, 1.18M)

thfg

winfag detected

Canary values wouldn't protect against buffer read overflows in any case, ya fucking dingus. It's only an indication of buffer writes.

I use dynamic by default, static if asked.

if a canary value is read, then that is a sign that a buffer has overflowed, dingus

Do you understand how canary values work? They protect against attacks that try to overwrite return addresses, because you can check if the canary value was modified. Reads do not modify anything. Heartbleed happened because of a faulty length check allowed an attacker to read outside the bounds of the buffer, and because cryptographic secrets were stored in known locations in memory, this flaw was particularly painful because the attacker would know where to look for them.

Memory layout randomization would obviously not prevent the flaw that allowed the attacker to read out of bounds, but it would have seriously diminished the effectiveness of said attack because it would be statistically less likely that you would be able to read from the sensitive memory locations.

>They protect against attacks that try to overwrite return addresses

That's one application of canary values, but that isn't their only implementation.

>Reads do not modify anything.

Which makes memory corruption checking canaries useless, yes, well done, but not canaries that cause alarm when read. What said is completely correct and rather self-explanatory. There are different types of canaries, you're just confusing them.

Canaries can be used for checking if a buffer's end has been overwritten or overread. You're only familiar with the former. There's some academic papers on the latter, but they've escaped my mind at the moment. Read more.

Attached: 145368527400.png (300x384, 172K)

>"What said is completely correct and rather self-explanatory"
>provides no explanation of how such a magical solution would even work
I mean, at least make an effort, man.

Attached: bait-k.gif (199x199, 571K)

>dynamic linking
what next, dynamic typing? negro

>Expects me to spoonfeed him this hard for free

Overflow checking canaries work by seeing if the canary has been overwritten, and overread checking canaries work by seeing if the canary value been has passed into a piece of data.

If you understand how canaries work, then you understand how all implementations of canaries work. One checks for writes, the other checks for reads. Very simple, and again, self-explanatory. If this is bait, then string comparisons must be gigabait.

If you are still confused and think an implementation of this is magical like a 55 year old boomer who's using Facebook for the first time, then learn assembly and eventually compiler design. You can implement a canary that checks for reads by validating the data that was read from a specific buffer... which included the canary at the end (assuming an out-of-bounds read happened).

I could write an example in ARM, but I honestly cannot be bothered. The information is here for you to do it yourself as an exercise. This is slightly harder than FizzBuzz, but the issue with overread canaries is large overhead, which is why nobody talks about them.

Attached: 1517388395892.gif (500x375, 2M)

Dynamic linking is fucking garbage.
To exploit the linker for code injection.

>and overread checking canaries work by seeing if the canary value been has passed into a piece of data.
Literally how? You're obviously full of shit. You could easily provide a link or explain how this works, instead you just go on about how self-explanatory it is.