1. 23

  2. 4

    Ok, this surprised me…

    This seems to be a major clusterfuck. Looking at the sudoers man page, it spends some time explaining how use_pty prevents a dangerous attack, just to then say: “This flag is off by default.” Which of course leaves the question: WHY? You know you have a major security vulnerability, you have a mitigation in place, and it is “off by default”?

    For su the same applies, though you cannot even set this in a config file.

    1. 3

      On Debian, use_pty is enabled by default in the shipped configuration file. This is quite recent (added two years ago).

      1. 2

        Isn’t it off by default to protect non-interactive sessions from wonky output? At least that’s the message I get from the linked article.

        1. 3

          “Wonky output” vs. “major security vulnerability”: Choose your priorities.

      2. 2

        This is a great example why it’s not a good idea to do things like write your own sudo by yourself (unless you’re just doing it for kicks and giggles). Security is hard. There are just too many random edge cases in our operating systems for one lone brain to consider.

        1. 5

          I mean… yes, but the original sudo seems vulnerable, it has an optional protection, and that is off by default.

          It appears sudo itself does everything wrong here.

          1. 2

            Oh don’t get me wrong, I totally agree we could benefit from a new sudo that’s less complex, has better defaults, and is written in a memory-safe language. I’m just saying that doing so alone without the support of other experts seems like a bad idea.

            1. 3

              this particular bug has nothing to do with memory-safety

        2. 2

          So… which operating systems protect against this by default? I’m hoping at least some do…

          1. 4

            The Linux kernel commit linked on the post mentions at least this:

            3 years ago OpenBSD entirely removed TIOCSTI[2], Android has had it filtered for longer[3], and the tools that had historically used TIOCSTI either do not need it, are not commonly built with it, or have had its use removed.

          2. 1
            [river@river Downloads]$ su
            [root@river Downloads]# su river
            [river@river Downloads]$ python inj.py id
            Traceback (most recent call last):
              File "/home/river/Downloads/inj.py", line 11, in <module>
                fcntl.ioctl(0, termios.TIOCSTI, char)
            OSError: [Errno 5] Input/output error
            [1]+  Stopped                 su river

            what am i doing wrong?

            1. 3

              That is how it looks for me on a kernel 6.2 with the option mentioned in the post disabled. However that is very bleeding edge. On what system are you?

              1. 2

                I use arch linux

              2. 1

                Do you have a dev.tty.legacy_tiocsti sysctl?