Dubious security vulnerability: Disk space consumption

Today's dubious security vulnerability goes like this:

The $RECYCLE.BIN directory can be used to launch a denial of service attack that is not detected by any current anti-malware software. An attacker can create a file in a user's Recycle Bin directory and write to it, making it larger than the configured Recycle Bin maximum size, and eventually consume all the space on the hard drive, rendering the drive unusable.

Um, yeah, but so?

The default security on each user's Recycle Bin folder grants access only to Administrators, System, and the owner of the Recycle Bin. Therefore, if you are a regular user, you cannot attack other users' Recycle Bins. All you can do is attack yourself.

Why pick on the Recycle Bin directory? You can "attack" the system in the exact same way by creating a file in any directory you like, and writing to it until you run out of disk quota. And if your disk quota is unlimited, then you can fill the hard drive.

In other words, a user who has permission to fill the hard drive can attack the system by filling the hard drive. If you don't like that, then don't give the user permission to fill the hard drive!

Bonus chatter: There would be an issue if creating files in the Recycle Bin allowed you to circumvent security or exceed your quota, but that doesn't appear to be what the reporter is concerned about. Disk space occupied by the Recycle Bin is still charged against your quota.

That reminds me back in my school days that one way to deal with being over quota is to mail files to yourself. The space occupied by your mailbox (or as we called it your "virtual card reader") had a separate quota from disk space, so you could use both your mailbox and your regular disk space (or as we called it, your "DASD") to store files. Of course, you didn't want to keep files in your mailbox for long, because once that went over mail quota, messages would start getting deleted automatically, oldest first. But it would buy you some time until you could get things under control.

Comments (18)
  1. DWalker says:

    I remember a similar kind of thing, way back on a mainframe system, where users could create files and then attach user permissions to them. The user permissions were in the form of arrays, one record per target user, which you attached to the files.

    The space taken by the permission arrays (which was normally small) was not charged against the file owner. You could encode any arbitrary data in the permission arrays, and therefore store lots of stuff without being charged (real money) for the space. However, it would have been very unwieldy… A friend and I figured all of this out and decided it wasn’t worth the effort.

    We discussed this with the IT supervisors and they said “yes, we know that this is a theoretical way to bypass space quotas. We are not worried”. I don’t know that anyone ever exploited this.

  2. alegr1 says:

    Does the vulnerability still exist when any unprivileged user can open a system file without FILE_SHARE_READ/FILE_SHARE_WRITE, and then legit system services will not be able to open the file (like an executable) for execute/read?

    It would make more sense if exclusive mode was ignored if an used doesn’t have write privileges to a file.

    1. ranta says:

      That was fixed in Windows 8 for Windows Store apps. They have to use CreateFile2, which fails if dwShareMode does not contain FILE_SHARE_READ and the security descriptor of the file does not grant FILE_GENERIC_WRITE access to the caller. FILE_DISALLOW_EXCLUSIVE activates this restriction in the kernel. That flag is not documented in NtCreateFile or ZwCreateFile, but it is in [MS-FSA].

  3. Andreas says:

    I remember back at uni there was a time when there were no regular jobs running to clean the local tmp directory on each machine. We used it to install various games and with a pretty big probability the games would still be there the next time we came around. Then one day the admins decided to have a job clean the local tmp directories each night and the good times were over…

  4. alegr1 says:

    Oh, and there was another old, but still unfixed memory quota-related vulnerability of serial.sys. An user could post unlimited number of increased size SET_QUEUE_SIZE IOCTLS behind a pending READ, without charging memory quota, thus exhausting the nonpaged pool.

  5. cheong00 says:

    Will it still be a problem if the coparate IT policy requires the administrators to set “Users” to D drive and therefore the only places that the user should have write access ought to be temp\Desktop\Documents folders in D drive only?

    I think those policies need to check for rules to disable “Recycle Bin” for C drive as well.

  6. Raymond’s usual dismissal of such type of “vulnerabilities” (which I used to agree with), is that if something is already running on a system with admin rights, it can do whatever it wants, so there’s no point focusing to recycle bin or any other particulars. However I recently came across evidence that “things” can penetrate your system through a back door and automatically elevated themselves to fully admin exploiting loopholes in windows e,g, see
    so it isn’t always the users fault :)

    1. cheong00 says:

      “One important thing to know is that UAC is not a security boundary.”

      Quote: https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac/

      1. Medinoc says:

        Wait, is “always notify” still safe, or are there elevation attacks that bypass even it?

        1. Pally Sandher says:

          Always notify is still safe and also that ‘blog’ the OP linked is more than 2 years old. I’d test it’s claims are still relevant before you commence panicking.

          1. Darran Rowe says:

            Even though the linked post is two years old, the actual issue is 6. It has also been known about, and even posted about, since the Windows 7 pre-release days. Every now and again someone rediscovers it, but I wouldn’t be surprised if it’s still in 10.
            So if UAC hasn’t changed in 6 years, then why haven’t we had much more abuse of UAC?

          2. cheong00 says:

            It should still be relevent. Try search for “UAC task scheduler” to find out how many technical articles/blogs use/abuse it to work around UAC in different scenario without need to turn UAC off. “Fixing” that would be breaking change for those people.

            IMO the only way to “fix” without breaking it would be to spawn elevation prompt whenever “run with highest privileges” is checked and the use if “administrative group” member, but that would require user to fill in all the task’s detail again, and still won’t fix the problem to add those tasks with “schtasks /rl highest” command (Command utilities could be run by scripts. If it’ll generate consent only on some combination of windows build number + switches, it’d be likely to break those scripts using it).

    2. __klg says:

      Not sure what you mean. If they elevate to “themselves to fully admin” (which is what the whole hatchway point is about), then what are we discussing here?

    3. Darran Rowe says:

      Actually, that is a side effect of the process white listing, and is the user’s fault.
      The article itself does make reference to the fact that it only works on the default UAC settings, and if you set UAC to “Always notify”, which turns off process white listing, then this attack cannot work.
      In fact, if you look at the UAC settings themselves, there is the information tip that clearly mentions the recommended use case. For the default settings, it says “Recommended if you use familiar applications and visit familiar websites” where always notify states “Recommended if you routinely install new software and visit unfamiliar websites”.
      From those, it is easy enough to see that the default UAC settings are tailored to “everyday use”, where you just run applications that you normally run, and visit websites that you normally visit. If you start using Windows to run untrusted software or visit untrusted websites, then you just can’t keep the UAC settings at default. In fact, in those situations, I normally go one step further and have that instance of Windows installed in a VM so it is isolated and can’t touch the system.
      To be honest, these days, I wouldn’t be surprised if UAC could be switched to always notify and have very little impact.

    4. Max says:

      If something can elevate itself to admin rights without admin permission or admin rights, then THAT is the security vulnerability, not whatever nefarious deed is done when admin rights are attained. Any vulnerability that starts with “first, an admin user needs to run this piece of code I have provided”, like the one you linked does, isn’t much of a vulnerability – that “bypass UAC” code doesn’t work unless it’s already on the other side of the airtight hatchway.

  7. not important says:

    Some of my college colleagues used newsgroups as an additional folder. They would post their PGP-encrypted files to Internet newsgroups. I am not sure if they did it for bragging rights, or because they really needed the additional hard disk space. Back in the day an external CDROM Writer would cost about $600, a writable CD $1; 1GB external SCSI drive would cost about $1,000.

  8. Ancient_Hacker says:

    Long ago, back when my files were stored on washing-machine sized skinny things, some smart guy figured out you could attach any number of specific user permissions to a file. So you could encode a file into A-Z0_9, the legal username characters, and hide it as permissions on some random file. We sure had a lot of free time in those olden days!

  9. Stan Thomas says:

    Direct Access Storage Device. Now there’s an acronym I haven’t heard for a while. Along with ABEND, EBCDIC and JCL.

Comments are closed.

Skip to main content