Announcement

Collapse
No announcement yet.

Clang 15 Lands Support To Randomize Structure Layout, Linux Prepares To Use It

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    I would bet money that OpenBSD picks this up for 7.2 in October.

    Comment


    • #12
      Originally posted by Raka555 View Post

      I know that, but the actual protection versus breakage potential is not worth it in my eyes.
      And what I meant is that if they are going to break things, I would rather see a size/speed benefit than a security benefit.
      I had to agree, as I also think Rust-like behavior of optimizing struct are more beneficial.

      Comment


      • #13
        Originally posted by Raka555 View Post

        I know that, but the actual protection versus breakage potential is not worth it in my eyes.
        And what I meant is that if they are going to break things, I would rather see a size/speed benefit than a security benefit.
        Yeah, being able to mark a struct as non-ABI and let the compiler optimize it, would be cool.

        Comment


        • #14
          Originally posted by coder View Post
          I don't love it. It basically just introduces another potential source of ABI breakage. It means that all code, which is using a certain struct, has to be compiled with the same seed parameter. And heaven help you if you need to use two (or more!) different libraries that were each built with different seed parameters!
          Bingo. And of course, it also means that every *language* that uses those structs needs the same capability in its compiler. If someone like MS had suggested this idea, the screams of "EEE" and "vendor lock-in" would be deafening.

          As you say, it's very much more security theater than actual security. It does, however, complicate "drive-by" malware, and if the seed isn't stored anywhere on the target machine I can see it being a meaningful-enough defense on that front, even though it would trivially fall to a targeted attack.

          Comment


          • #15
            Originally posted by arQon View Post
            it also means that every *language* that uses those structs needs the same capability in its compiler.
            There's a potential escape hatch, in that they could expose an option (maybe they already do?) for outputting header files with the reordered structs. However, it's far from ideal, not least because those header files would already be preprocessed (i.e. not very developer-friendly, if you had to look at them).

            Comment


            • #16
              Originally posted by Raka555 View Post

              I know that, but the actual protection versus breakage potential is not worth it in my eyes.
              And what I meant is that if they are going to break things, I would rather see a size/speed benefit than a security benefit.
              It's a compiler option. And yes, testing and trying to break things is essential part of security. It is just one tool more to toolbox.

              Comment


              • #17
                Originally posted by IndioNuvemChuva View Post

                I take it you like your exploits to run as fast as possible?
                Hammer, see nail.

                Comment

                Working...
                X