Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > rocksolid.shared.security > #60 > unrolled thread

WIndows 10 NTFS bug

Back to article view | Back to rocksolid.shared.security

Contents

  WIndows 10 NTFS bug Anonymous <poster@anon.com> - 2021-01-15 13:25 -0800
    None Anonymous <poster@anon.com> - 2021-01-15 17:20 -0800
    Re: WIndows 10 NTFS bug Anonymous <poster@anon.com> - 2021-01-16 04:22 -0800
    None Anonymous <poster@anon.com> - 2021-01-16 06:09 -0800
    Re: WIndows 10 NTFS bug Anonymous <poster@anon.com> - 2021-01-16 07:28 -0800
    None Anonymous <poster@anon.com> - 2021-01-16 16:00 -0800

#60 — WIndows 10 NTFS bug

[Multipart message — attachments visible in raw view] — view raw

Ever wanted to crash your NTFS hd under Windows 10 ?
Seems like one command is enough:
C:/:$i30:$bitmap
Can be delivered in many different formats, does not need privileges....perfect

https://www.bleepingcomputer.com/news/security/windows-10-bug-corrupts-your-hard-drive-on-seeing-this-files-icon/

[toc] | [next] | [standalone]

#61 — None

Un*x filesystems suffer a similar fate, this will probably be throw under the rug and never addressed.

-- 
Posted on def2

[toc] | [prev] | [next] | [standalone]

#62

>>cb5a02be0a825bfd8f
>Un*x filesystems suffer a similar fate,
If that is true, what is the command triggering it ?

-- 
Posted on def2

[toc] | [prev] | [next] | [standalone]

#63 — None

>>acdc5a9b4367c051b2
unzip $file, tar -xf $file, cpio -i -F $file, mkdir $garbage, touch $garbage, mv file $garbage, etc. It's similar not the same but from a quick search ntfs and redsea have the same fundamental flaws so this method can also be used. This is not anything special, it's bad filesystem design.
Make inodes with names out of the utf8 range until the filesystem corrupts and loses data. Difficulty is on how resilient the filesystem is, this isn't a new concept so it won't work easily on modern filesystems.
Bonus points for making random shell commands launch or all of the superblocks, journal and root inode lost.
This isn't significant unless you can make a poc that directly targets the root inode and all the superblocks, permanently trashing the filesystem, with great accuracy.

-- 
Posted on def2

[toc] | [prev] | [next] | [standalone]

#64

>>9bc982e330023840e6
that is not the same by far. exhausting inodes with time is not the same as a oneliner that causes immediate reboot and leaves the hd broken after.

-- 
Posted on def2

[toc] | [prev] | [next] | [standalone]

#65 — None

>>1a7c630ada66f0c8f1
You missed it could be a one liner, a single touch with the right garbage that causes a reboot from the kernel and blasts away all the recovery and inode data but it will look more complicated than C:/:$i30:$bitmap . This requires information leaks to pull off automatically which could also be automated with a single touch but how big the argv becomes is the problem, archives are a more likely deployment over garbage filename downloads. It's still not the same but similar by the fundamental concept of trusting the users' data, a broken design.

-- 
Posted on def2

[toc] | [prev] | [standalone]

Back to top | Article view | rocksolid.shared.security

csiph-web