GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 10-Dec-2024 08:02:39 JST Will Dormann Will Dormann

    Back when I was poking around with filesystem fuzzing stuff years back, I noticed something odd:

    An EXT filesystem can tell the Linux OS how it should behave "if" the filesystem is corrupt, including triggering a kernel panic. In a world where USB thumb drives exist, this seems... not ideal.

    Let's see what happens if we plug such a mass storage device into a fully patched Chromebook in 2024...

    Oh.

    In conversation about 5 months ago from infosec.exchange permalink

    Attachments


    • MortSinyx likes this.
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 10-Dec-2024 22:40:09 JST Rich Felker Rich Felker
      in reply to

      @wdormann ext filesystems also have file ownership, suid capability, etc. The worst of this can be mitigated with mount options (maybe panic on error can too?) but ultimately it's not a suitable fs for external media and should not be auto mounted by anything unless you have a sandboxed FUSE driver for it in place of the kernel one.

      In conversation about 5 months ago permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Will Dormann (wdormann@infosec.exchange)'s status on Tuesday, 10-Dec-2024 22:40:10 JST Will Dormann Will Dormann
      in reply to

      The man page for tune2fs is pretty clear about this capability.

      The person who writes the data to the USB mass storage device can specify that both:
      1) The OS that reads the device should panic if the filesystem has an error.
      2) The filesystem has an error.

      🤦♂️

      In conversation about 5 months ago permalink

      Attachments


      1. https://media.infosec.exchange/infosec.exchange/media_attachments/files/113/625/357/706/842/942/original/eb1dc20311b962a6.png
      Rich Felker repeated this.
    • Embed this notice
      chort ↙️↙️↙️ (chort@infosec.exchange)'s status on Tuesday, 10-Dec-2024 22:40:30 JST chort ↙️↙️↙️ chort ↙️↙️↙️
      in reply to

      @wdormann It's funny (and rather cringe-inducing) to us infosec folks, but to 99% of developers they will always say "why would anyone do that?"

      The vast majority just truly have no concept that anyone might want to act maliciously. If the engineer themself wouldn't perform a malicious action, they cannot conceive that anyone else would.

      I have run into this issue so many times during my career. I now assume that no engineer will ever consider possible malicious actions taken against their code. To the extent that they do consider malicious actions, it will only be things that they themselves would do.

      In conversation about 5 months ago permalink
      Fish of Rage likes this.
      Rich Felker repeated this.
    • Embed this notice
      AmbianceAsunder (ambianceasunder@infosec.exchange)'s status on Tuesday, 10-Dec-2024 22:40:45 JST AmbianceAsunder AmbianceAsunder
      in reply to
      • chort ↙️↙️↙️

      @chort @wdormann infosec folk here, however I am asking myself the same question - not as in “who cares, who would do this” but moreso “what how where and when does this break stuff leading to potential compromise outside of the obvious FUBAR case for the system itself?” In other words, what specifically is this a precursor to or does this actually keep a system down? I’m certain I’m missing something here or am ignorant of a topic

      In conversation about 5 months ago permalink
    • Embed this notice
      David Zaslavsky (diazona@techhub.social)'s status on Tuesday, 10-Dec-2024 22:42:05 JST David Zaslavsky David Zaslavsky
      in reply to
      • chort ↙️↙️↙️

      @chort @wdormann Funnily enough, my first thought was indeed "why would anyone do that" but with "that" being "allow the filesystem to trigger a kernel panic" 😂

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 10-Dec-2024 22:42:40 JST Rich Felker Rich Felker
      in reply to
      • Leonard Ritter
      • chort ↙️↙️↙️

      @lritter @chort @wdormann This is an irresponsible take.

      In conversation about 5 months ago permalink
    • Embed this notice
      Leonard Ritter (lritter@mastodon.gamedev.place)'s status on Tuesday, 10-Dec-2024 22:42:42 JST Leonard Ritter Leonard Ritter
      in reply to
      • chort ↙️↙️↙️

      @chort @wdormann i'm a software engineer. if i were considering at every point how any of my designs could be used to produce malicious behavior, then i would cease to be a software engineer and instead work in infosec.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 10-Dec-2024 22:47:25 JST Rich Felker Rich Felker
      in reply to
      • Leonard Ritter
      • chort ↙️↙️↙️

      @lritter @chort @wdormann Sorry for being terse. Really tho we need genuine software engineers committed to producing stuff that's safe and robust not just halfway working under favorable conditions. We don't need them getting sucked away into infosec.

      In conversation about 5 months ago permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Leonard Ritter (lritter@mastodon.gamedev.place)'s status on Tuesday, 10-Dec-2024 22:47:26 JST Leonard Ritter Leonard Ritter
      in reply to
      • chort ↙️↙️↙️
      • Rich Felker

      @dalias @chort @wdormann as a good C librarian it better should be your duty to believe that this take of mine is irresponsible.

      In conversation about 5 months ago permalink
    • Embed this notice
      Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 10-Dec-2024 22:54:48 JST Rich Felker Rich Felker
      in reply to

      @wdormann Indeed, -o errors=continue fixes this. ChromeOS is being bad automounting ext fs on external media without it. Same as mounting without -o nosuid would be a bug.

      In conversation about 5 months ago permalink
    • Embed this notice
      翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Wednesday, 11-Dec-2024 15:29:24 JST 翠星石 翠星石
      in reply to
      @wdormann >the Linux OS
      What is this Linux OS you speak of?

      After all, the kernel, Linux doesn't operate on its own and therefore it cannot possible be and *operating* system.


      Chromebooks run Gentoo GNU/Linux with the freedom removed.
      In conversation about 5 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.