Announcement

Collapse
No announcement yet.

CVE-2017-9445: systemd Hit By New Security Vulnerability

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

  • #81
    Originally posted by pal666 View Post
    but if you demand to rewrite all software in new toy without backwards compatibility, then all backwards compatibility is gone
    1. Nobody have said rewrite all software in Rust. systemd-resolved is new enough that it should have been written in Rust from the start.
    2. Just because you rewrite a software does not mean that all backwards compatibility is gone.
    The project I'm currently working on at work is a rewrite of a very old software that is not maintainable, however it is used with a lot of constant traffic in production from many countries so the first part of the project was writing a huge test suite over the old software an API that we now use against our rewrite to guarantee backwards compatibility with the current code.

    Comment


    • #82
      Originally posted by pal666 View Post
      no, imbecile, systemd does not depend on systemd-resolved at all
      At one point did I claim the dependency chain went that way?

      Originally posted by sdack View Post
      *lol* Of course not. You only shouldn't dislike without reason. You still don't know me, but you thought I was a systemd fanboy. Now you think I'm cute, but the truth is, I'm awesome and you still only suck. *lol* Or how do you feel now? I bet you feel like lying. So give me your next comment. I know it's going to be something about how you're trying to keep your boat afloat. Looking forward to it. Bring the hate.
      I've explained the multitude of reasons why I don't like systemd (being a textbook example of feature creep, the way they handle bugs and knowingly creating way too big of an attack surface for something that can have catastrophic consequences if compromised to name a few) and I really can't be bothered to explain them in detail every time I express my dislike for the thing.

      But hey, it's like like I can stop you from acting like a 12-year-old (I can't imagine anyone writing like you without being one or being mentally handicapped) or acting like there's nothing wrong a fundamentally flawed piece of software. The Titanic was totally unsinkable and crewed by people who totally knew what they were doing until it ran into an iceberg despite being warned about them in advance and sank as a result.
      Last edited by L_A_G; 07-02-2017, 06:48 PM.

      Comment


      • #83
        Originally posted by L_A_G View Post

        I've explained the multitude of reasons why I don't like systemd (being a textbook example of feature creep, the way they handle bugs and knowingly creating way too big of an attack surface for something that can have catastrophic consequences if compromised to name a few) and I really can't be bothered to explain them in detail every time I express my dislike for the thing.
        Lennart wrote that using audit=0 at the kernel command line stops systemd to call syscalls. At the Amlogic S912 boot when it is critical timings, the shit still calls syscall 279. It stops doing it after the boot, luckily. Lennart and redhat thinks that this looks nice in the logs:

        Code:
        [    0.000000] Linux version 3.14.29-g1f4b687b-dirty (root@carrizo) (gcc version 4.9.4 (Linaro GCC 4.9-2017.01) ) #47 SMP Sat Jul 1 15:42:10 EEST 2017
        [    0.000000] Kernel command line: root=LABEL=ROOTFS rootflags=data=writeback rw co
        nsole=ttyS0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.repair=yes net.ifnames=0 mac=C4:2F:AC:99:32:19 audit=0
        
        
        ...
        [   76.551100] systemd[3324]: syscall 279
        [   76.551149] Code: aa0503e4 aa0603e5 aa0703e6 d4000001 (b13ffc1f)
        [   76.555678] CPU: 2 PID: 3324 Comm: systemd Not tainted 3.14.29-g1f4b687b-dirty #4
        7
        [   76.563344] task: ffffffc0644e7000 ti: ffffffc0650c0000 task.ti: ffffffc0650c0000
        [   76.570943] PC is at 0x7fb7816754
        [   76.574378] LR is at 0x7fb7b3eaec
        [   76.577819] pc : [<0000007fb7816754>] lr : [<0000007fb7b3eaec>] pstate: 20000000
        [   76.585325] sp : 0000007ff88dbc90
        [   76.588768] x29: 0000007ff88dbc90 x28: 0000007fb7c6d320
        [   76.594173] x27: 00000055a3145140 x26: 0000005590429000
        [   76.599634] x25: 00000000055d4a80 x24: 0000005590429308
        [   76.605041] x23: 00000055903d6bed x22: 0000007fb7c6f000
        [   76.610473] x21: 0000000000000000 x20: 0000007ff88dbd80
        [   76.615911] x19: 00000055903d6bed x18: 0000000000000000
        [   76.621340] x17: 0000007fb7816730 x16: 0000007fb7c6fca8
        [   76.626777] x15: 0000000000000010 x14: 0000000000000022
        [   76.632212] x13: 006c6f72746e6f63 x12: 2e6d65747379732f
        [   76.637662] x11: 0000000000000000 x10: 00000000aaaa0000
        [   76.643074] x9 : 000000000003ffff x8 : 0000000000000117
        [   76.648511] x7 : 0000000001000101 x6 : 0000000001000101
        [   76.653939] x5 : 00000055903d6c00 x4 : 0000000000000029
        [   76.659373] x3 : 0000000040100401 x2 : 0000000000000000
        [   76.664809] x1 : 0000000000000001 x0 : 00000055903d6bed
        
        [   76.674207] systemd[3349]: syscall 279
        same shit again
        Programmers at redhat have no sense at all. When they write that audit=0 stops systemd doing syscalls and it is still doing.
        Last edited by debianxfce; 07-03-2017, 03:30 AM.

        Comment


        • #84
          Originally posted by L_A_G View Post
          I've explained the multitude of reasons why I don't like systemd (being a textbook example of feature creep, the way they handle bugs and knowingly creating way too big of an attack surface for something that can have catastrophic consequences if compromised to name a few)
          [CITATION NEEDED]

          systemd PID1 should've a much smaller attack surface than sysvinit.
          With sysvinit it's rather easy to cause all sorts of race conditions due to its overly messy nature.

          Comment


          • #85
            Originally posted by unixfan2001 View Post

            [CITATION NEEDED]

            systemd PID1 should've a much smaller attack surface than sysvinit.
            With sysvinit it's rather easy to cause all sorts of race conditions due to its overly messy nature.
            Try systemd with tvboxes and 3.14 kernels. Then you see what is messy and causes race conditions at boot, see my prev post of messy logs. There is no audit service anymore that you could disable. Soon redhat distribution consist only of systemd, how handy it is to maintain zillions of lines of integrated code...
            Last edited by debianxfce; 07-03-2017, 07:16 AM.

            Comment


            • #86
              Originally posted by unixfan2001 View Post
              [CITATION NEEDED]

              systemd PID1 should've a much smaller attack surface than sysvinit.
              With sysvinit it's rather easy to cause all sorts of race conditions due to its overly messy nature.
              The fact that sysvinint doesn't do a particularly good job at keeping itself safe from attacks trough good development practices doesn't make it acceptable for systemd to cause unnecessary security risks because of equally bad or worse practices. Only children (and the child minded) think that something bad is acceptable because someone else does it.

              Seriously, when the developers of an init system decide to add more and more functionality to the point where the only thing missing is a built-in email client it doesn't take an expert to realize something is badly wrong.

              Comment


              • #87
                Originally posted by pal666 View Post
                well you could stop right there
                I could, but let's see where this thought experiment goes.

                pdns-recursor has only had a few vulns over the years and would largely fill the role that systemd-resolved does. it is also largely battle tested with a great speed and good reputation.

                this is one such example code base that could have been used to build on top of to make resolved.

                The main reason I make the argument that going the DIY route was wrong is because when this project was announced, the people who knew what they were doing told the people who had never written a dns resolver before that it was hard, that there were a lot of things that could break and they would be better off not doing it.

                well, they ignored that and ended up exactly in the place that they were told they were going to be.

                Comment


                • #88
                  Originally posted by pal666 View Post
                  no, we can continue when you name foss dns which solves issues solved by systemd-resolved and does not have vulnerabilities. i'm in good mood today, so you can name two projects each having only one of those properties. and strawman was on your side when you implied that somewhere exists code which systemd people are refusing to use for no particular reason
                  Seems you have already forgotten what another poster posted. Or prefer to pretend it's not there.
                  https://lists.dns-oarc.net/pipermail...ne/014964.html

                  Now, tell me again about the advantages of systemd-resolved. Feels like pretty much anything is better than this thing you defend with a bare chest.

                  Originally posted by pal666 View Post
                  logic is simple: systemd-haters are imbeciles, they "predict" truisms
                  Reminds me of women. Emotion - "they attack my love-child" is primary. All "logic" revolves around it, rational thinking escaped the home.

                  Originally posted by boxie View Post
                  i think that might be a tad harsh. they want the features true, but every dev tries their best to do good work. The opportunity to do something new is always a strong pull to DIY, but that gets you into NIH territory.

                  there have been plenty of times that I would have written something myself - because it was a cool project, only for my boss to say "here, use this existing awesome tool that already does the job"
                  May sound harsh but is it really? OpenBSD devs follow the philosophy of not allowing a feature/component into RELEASE before it's ready. And it's considered "ready" when it feels like ready (feature complete). Linux could really benefit from similar mental approach, when dealing with critical system components. It's fucking common sense.

                  Originally posted by F.Ultra View Post
                  The vulnerability just found have nothing to do with the things in that prediction which was ramblings about the binary to xml and back translation that systemd-resolved uses in order to pass the DNS data over D-BUS.

                  And if any one didn't notice (since it wasn't advertised everywhere due to not being systemd) there where a CVE issued early today for Bind.
                  Arguable. Actual vulnerability was caused by programming error. Prediction predicted vulnerabilities based on module design. True - literally taken, both are different issues. At certain level though - both, programming errors and faulty design are results of haphazard approach to the whole thing.

                  Why should I care about bind? When there is BSD-licensed unbound. Just feels odd, because multiple posters have thrown bind and it's vulnerabilities on my face. As a BSD user I can't literally remember when was the last time I had to use bind. Regardless, systemd-resolved and bind are not comparable. The latter is actually functional as DNS server. systemd-resolved still has about 40 open bugs according to systemd's github page where people struggle with basic dns function-related errors.
                  Last edited by aht0; 07-04-2017, 04:32 PM. Reason: Edit: I did not notice one reply to my post (bottom-end add-on now)

                  Comment


                  • #89
                    Originally posted by L_A_G View Post

                    The fact that sysvinint doesn't do a particularly good job at keeping itself safe from attacks trough good development practices doesn't make it acceptable for systemd to cause unnecessary security risks because of equally bad or worse practices. Only children (and the child minded) think that something bad is acceptable because someone else does it.

                    Seriously, when the developers of an init system decide to add more and more functionality to the point where the only thing missing is a built-in email client it doesn't take an expert to realize something is badly wrong.
                    Again with the BS?
                    None of that is part of PID1.

                    systemd PID1 has a consistently smaller attack surface than sysvinit.

                    Can you people please, for the love of god, learn the difference between a piece of software and a project/monorepository that may contain several pieces of software?
                    Your complaints about systemd are like me complaining about a bug in Thunderbird but referring to it as "Firefox" or "Mozilla".

                    Comment


                    • #90
                      Bad comparison. While installing Firefox, you do not get Thunderbird forcibly installed along with it..

                      Comment

                      Working...
                      X