• naurM
      link
      fedilink
      Polski
      arrow-up
      1
      ·
      edit-2
      7 months ago

      Tę podatność w su/sudo próbuje rozwiązać najnowszy wynalazek Poetteringa - run0.

      • Lacky
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        Aż mnie zaciekawiło jak to działa:

        “But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.”

        Nie mam chwilowo czasu na jakąś dokładniejszą analizę run0, ale w prawym kolanie wyczuwam, że będą tutaj ataki na komunikację z “service manager” i wymuszenie na nim by powołał odpowiedni proces. W przeszłości już było ileś takich błędów, gdzie dało się eskalować uprawnienia, poprzez odpowiednie zagadanie do procesu, który robił coś takiego na potrzeby realizacji pewnej funkcjonalności.

  • サぺルOP
    link
    fedilink
    Polski
    arrow-up
    1
    ·
    7 months ago

    Nie podoba mi się api biblioteki gościa, ale wpis jest fajny.

  • naurM
    link
    fedilink
    Polski
    arrow-up
    1
    ·
    7 months ago

    Nie do końca zgadzam się z argumentem, że wskaźniki są rozdmuchanym problemem.
    Autor wpisu skupił się na problemie przynależności (ownership) wskaźników, którego faktycznie można uniknąć odpowiednim designem API.
    Nie wspomniał za to o kwestii sprawdzania zakresów tablic, który obecnie rozwiązuje się lekkimi abstrakcjami (slice, span, itp.) i automatyczną iteracją (range for).
    Przemilczał też, że (ze względu na brak generyczności) uniwersalnym typem wskaźnika w C jest void* (ewentualnie char*). W związku z czym powiększa się liczba miejsc, gdzie programista rzutuje swoje struktury na taki bazowy wskaźnik a później ręcznie odtwarza zagubione w ten sposób informacje o typie.

    Ja rozumiem, że takie proste języki jak C mają swój urok, bo ich minimalizm redukuje programiście wybór dostępnych rozwiązań problemu.
    Tylko wydaje mi się, że w 2024 mamy już kilka nowoczesnych języków, które są znacznie bezpieczniejsze i tak samo minimalistyczne jak C.

    • サぺルOP
      link
      fedilink
      Polski
      arrow-up
      1
      ·
      7 months ago

      Ostatnio jest wysyp tego typu wpisów.

      np.: https://danielchasehooper.com/posts/shapeup/

      Traktuje to w kategorii programowania rekreacyjnego. Przy okazji można się dowiedzieć co i gdzie śmierdzi w bibliotekach.

      Dziękuję, że wspomniałeś o tych abstrakcjach. To był odpowiedni czas. Wyobraziłem sobie dlaczego są lekkie.

      Uważam, że jeśli ktoś sobie koduje w C i przez większość czasu kompilator nie pisze mu warningów, errorów, a program nie kończy się segfaultem, to może sobie kodować dla przyjemności. Bo raczej wie co robi. Miło się programuje w tym co się zna. Przy okazji mogą powstać fajne rzeczy.

      Fajnie, że są nowe języki. Są też o nich podobne, zabawne opracowania u tsoding i jdh. Nie umiem tego oglądać, ale są to inspirujące rzeczy nawet po samym tytule.