ext2 and ext3 block reservations can be bypassed
Usually the last 5% of the diskspace on ext2 and ext3 filesystems are reserved for root. But I just realized that they can be bypassed by redirecting the output from a suid root program to a file.
This command will keep writing beyond the 95% limit:
while true ; do mount ; done >filename
This was tested on a 2.4.19-pre8-ac1 kernel. Does this problem exist on all other kernels as well, and how severe is this problem?
It might be better to only allow write() if the user was also allowed to do that when open() was called.
Signature · 2 lines
Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:[email protected]
Quoted 7 lines · Kasper Dupont
Usually the last 5% of the diskspace on ext2 and ext3 filesystems are reserved for root. But I just realized that they can be bypassed by redirecting the output from a suid root program to a file.
This command will keep writing beyond the 95% limit:
while true ; do mount ; done >filename
Hej Kasper,
Sure you were not running the shell as root ? :)
The redirection is handled by your shell, mount doesn't have anything to do with the '>filename' part.
Actually, the more fun test is to
mount > /etc/passwd
or
mount > /dev/hda
But this won't work either, unless your shell (and therefore you as a user, suid programs or not) have the permissions as required.
In short: I don't think you are seeing what you think you are seeing ;)
Signature · 6 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............:
His test was different.
He opened a file in a legal situation (shell can create a new file), and then forked off a suid process over and over with the stdout of that process set to a dup of the shell's already open fd.
It's perfectly legal for the shell to sit around with a file open and pass it off to a child, even if the disk is full.
It's also perfectly legal for root to write to the fd, even if the disk is full (for normal users).
It just happens that the suid program wasn't the one who chose what file it was going to write stdout to - the shell did.
Thus, the security violation.
mount > /etc/passwd doesn't work, because the shell can't open /etc/passwd for writing.
-J
Quoted 38 lines · Jakob ?stergaard
Quoted 7 lines · Kasper Dupont
Usually the last 5% of the diskspace on ext2 and ext3 filesystems are reserved for root. But I just realized that they can be bypassed by redirecting the output from a suid root program to a file.
This command will keep writing beyond the 95% limit:
while true ; do mount ; done >filenameHej Kasper,
Sure you were not running the shell as root ? :)
The redirection is handled by your shell, mount doesn't have anything to do with the '>filename' part.
Actually, the more fun test is to
mount >/etc/passwd
or
mount >/dev/hdaBut this won't work either, unless your shell (and therefore you as a user, suid programs or not) have the permissions as required.
In short: I don't think you are seeing what you think you are seeing ;)
Signature · 11 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob ?stergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Elladan
His test was different.
He opened a file in a legal situation (shell can create a new file), and then forked off a suid process over and over with the stdout of that process set to a dup of the shell's already open fd.
It's perfectly legal for the shell to sit around with a file open and pass it off to a child, even if the disk is full.
Quoted 7 lines
It's also perfectly legal for root to write to the fd, even if the disk is full (for normal users).
It just happens that the suid program wasn't the one who chose what file it was going to write stdout to - the shell did.
Thus, the security violation.
<shrug> relying on 5% in security-sensitive setup is *dumb*.
In that case you need properly set quota (better yet, no lusers with write access anywhere on that fs)..
There are worse holes problems 5% rule. E.g. you can create a
file with hole, mmap over that hole, dirty the pages and exit. Guess who ends up writing them out? Right, kswapd. Which is run as root. No suid applications required...
Quoted 8 lines · Alexander Viro
Quoted 5 lines · Elladan
It just happens that the suid program wasn't the one who chose what file it was going to write stdout to - the shell did.
Thus, the security violation.
Quoted 8 lines
<shrug> relying on 5% in security-sensitive setup is *dumb*.
In that case you need properly set quota (better yet, no lusers with write access anywhere on that fs)..There are worse holes problems 5% rule. E.g. you can create a
file with hole, mmap over that hole, dirty the pages and exit. Guess who ends up writing them out? Right, kswapd. Which is run as root. No suid applications required...
Regardless of whether it's a good thing to depend on security-wise, it is a problem to have something that appears to be a security feature which doesn't actually work.
Reading the documentation, I would expect that if I create an ext3 filesystem, reserve 20% of it for root, and then run a cron job as root that uses 16% of that filesystem periodically, that cron job will not actually fail whenever some luser decides they want it to.
I don't recall seeing it plastered in huge letters, "This space reserve is just a convenience feature, and can easily be circumvented by the user. You must never rely on it for anything."
Having unsupported security features is typically a bad idea.
-J
Elladan <[email protected]> said:
[...]
Quoted 3 lines
Regardless of whether it's a good thing to depend on security-wise, it is a problem to have something that appears to be a security feature which doesn't actually work.
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Quoted 11 lines · Horst von Brand
Elladan <[email protected]> said:
[...]
Quoted 3 lines
Regardless of whether it's a good thing to depend on security-wise, it is a problem to have something that appears to be a security feature which doesn't actually work.
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
But it *appears* to be a security feature. Thus, someone might incorrectly depend on it, unless it's clearly documented as otherwise. This is probably best considered a documentation issue. Instead of saying it's "reserved for root" etc., tools should indicate it's "reserved to prevent fragmentation, still accessible by root"
At least one document I recall seeing indicates that this reserve is so system software (eg. cron jobs) won't fail, and so root will still be able to log in when the disk is full. This interpretation makes it sound like a security feature - if it isn't meant as one, some effort should be made to ensure there's no confusion, or else someone might depend on the behavior.
-J
Quoted 6 lines · Elladan
Quoted 3 lines
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
But it *appears* to be a security feature. Thus, someone might incorrectly depend on it, unless it's clearly documented as otherwise.
So what. People rely on chroot() as security feature all the time and we don't "fix" it either. If you need security nothing but gaining knowledge about all details helps.
Quoted 5 lines · Horst von Brand
Elladan <[email protected]> said:
[...]
Quoted 7 lines
Quoted 3 lines
Regardless of whether it's a good thing to depend on security-wise, it is a problem to have something that appears to be a security feature which doesn't actually work.
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
My point was that anybody can use this space if they want to.
While this feature might not be intended to be used for security purposes, the documentation says the space is reserved for the super-user. And in many cases it would be convenient to use the feature for that purpose.
Since this would be a usefull feature for many people, and since it AFAIK cannot be acomplished with quotas, I suggest we find a way to make it work like most people would expect.
Would it cause any problems if the kernel ensured that the block reservations could not be bypassed by users?
I have not yet verified if the same problem exists when using quotas. (My kernel is compiled without quotas). But if it does I guess we all would like to have it fixed.
Signature · 2 lines
Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:[email protected]
1) You can always submit a patch, and see whether other people approve of it.
2) If you won't do it, why would somebody else working on something that provides lower latency to user process response time, or improvement to the IDE drivers, take the time to deal with this issue?
You need to either do 1), or convince somebody to do 2).
As it is, there are plenty of other denial-of-service type attacks that can be performed that would be more effective than the 'exploit' you have mentioned. Your proposal would need to be 'fix them all', if your complaint is that Linux has a security hole.
If you complaint is that an administrator might mistakenly believe that it is a security feature, I suggest your understand that this is merely one issue of quite a few. If the administrator is not aware of issues such as these, perhaps they should not be an administrator?
mark
Quoted 40 lines · Kasper Dupont
Quoted 5 lines · Horst von Brand
Elladan <[email protected]> said:
[...]
Quoted 7 lines
Quoted 3 lines
Regardless of whether it's a good thing to depend on security-wise, it is a problem to have something that appears to be a security feature which doesn't actually work.
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
My point was that anybody can use this space if they want to.
While this feature might not be intended to be used for security purposes, the documentation says the space is reserved for the super-user. And in many cases it would be convenient to use the feature for that purpose.
Since this would be a usefull feature for many people, and since it AFAIK cannot be acomplished with quotas, I suggest we find a way to make it work like most people would expect.
Would it cause any problems if the kernel ensured that the block reservations could not be bypassed by users?
I have not yet verified if the same problem exists when using quotas. (My kernel is compiled without quotas). But if it does I guess we all would like to have it fixed.
Signature · 7 lines
Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:[email protected] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
I went to google and attempted to find information about the root reserve space for ext2, as a user wondering about the feature would. I couldn't find any documentation that states it's purely a fragmentation and convenience feature. I did, however, find documents stating otherwise. Note how even Documentation/filesystems/ext2.txt states that it's a security feature?
If this is not a security feature, Documentation/filesystems/ext2.txt needs to be changed. Eg.,
"In ext2, there is a mechanism for reserving a certain number of blocks for a particular user (normally the super-user). This is intended to keep the filesystem from filling up entirely, which helps combat fragmentation. The super-user may still use this space. Note that this is not a security feature, and is only provided for convenience - various methods exist where a user may circumvent this reservation and use the space if they so wish. Quotas or separate filesystems should be used if reliable space limits are needed."
1. http://web.mit.edu/tytso/www/linux/ext2intro.html
Design and Implementation of the Second Extended Filesystem
[....] Ext2fs reserves some blocks for the super user (root). Normally, 5% of the blocks are reserved. This allows the administrator to recover easily from situations where user processes fill up filesystems.
2. Documentation/filesystems/ext2.txt
Reserved Space
--------------
In ext2, there is a mechanism for reserving a certain number of blocks for a particular user (normally the super-user). This is intended to allow for the system to continue functioning even if non-priveleged users fill up all the space available to them (this is independent of filesystem quotas). It also keeps the filesystem from filling up entirely which helps combat fragmentation.
3. Note what mke2fs prints:
3275 blocks (5.00%) reserved for the super user
It does not say "reserved to combat fragmentation"
-J
Quoted 17 lines · Christoph Hellwig
Quoted 6 lines · Elladan
Quoted 3 lines
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
But it *appears* to be a security feature. Thus, someone might incorrectly depend on it, unless it's clearly documented as otherwise.
So what. People rely on
chroot()as security feature all the time and we don't "fix" it either. If you need security nothing but gaining knowledge about all details helps.-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Notice how the space can only be filled up if a setuid program is used to actually fill it up. Even if it is a partial 'security feature', every administrator knows that setuid violates security in a non-natural way.
1) Provide a patch and see if it is accepted.
2) Convince somebody else that they should put time into features of questionable value such as this one.
mark
Quoted 76 lines · Elladan
I went to google and attempted to find information about the root reserve space for ext2, as a user wondering about the feature would. I couldn't find any documentation that states it's purely a fragmentation and convenience feature. I did, however, find documents stating otherwise. Note how even
Documentation/filesystems/ext2.txtstates that it's a security feature?If this is not a security feature,
Documentation/filesystems/ext2.txtneeds to be changed. Eg.,"In ext2, there is a mechanism for reserving a certain number of blocks for a particular user (normally the super-user). This is intended to keep the filesystem from filling up entirely, which helps combat fragmentation. The super-user may still use this space. Note that this is not a security feature, and is only provided for convenience - various methods exist where a user may circumvent this reservation and use the space if they so wish. Quotas or separate filesystems should be used if reliable space limits are needed."
1. http://web.mit.edu/tytso/www/linux/ext2intro.html
Design and Implementation of the Second Extended Filesystem
[....] Ext2fs reserves some blocks for the super user (root). Normally, 5% of the blocks are reserved. This allows the administrator to recover easily from situations where user processes fill up filesystems.
2.
Documentation/filesystems/ext2.txtReserved Space
--------------In ext2, there is a mechanism for reserving a certain number of blocks for a particular user (normally the super-user). This is intended to allow for the system to continue functioning even if non-priveleged users fill up all the space available to them (this is independent of filesystem quotas). It also keeps the filesystem from filling up entirely which helps combat fragmentation.
3. Note what mke2fs prints:
3275 blocks (5.00%) reserved for the super user
It does not say "reserved to combat fragmentation"
-J
Quoted 12 lines · Christoph Hellwig
Quoted 6 lines · Elladan
Quoted 3 lines
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
But it *appears* to be a security feature. Thus, someone might incorrectly depend on it, unless it's clearly documented as otherwise.
So what. People rely on
chroot()as security feature all the time and we don't "fix" it either. If you need security nothing but gaining knowledge about all details helps.Quoted 5 lines
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
A second method was proposed as well - create a file with a hole in it, map it, then dirty the pages in the hole and exit. This would not require suid.
This is basically a documentation issue, unless someone wants to go fix it. I wouldn't bother myself - it's ext[23] only and not really very useful.
The basic problem is this: the documentation states "This is intended to allow for the system to continue functioning even if non-priveleged users fill up all the space available to them." This states that it's a security feature. It does not work as intended - all users are privileged to do this - so the documentation should be updated.
I'll send a patch to someone later today.
-J
Quoted 101 lines · Mark Mielke
Notice how the space can only be filled up if a setuid program is used to actually fill it up. Even if it is a partial 'security feature', every administrator knows that setuid violates security in a non-natural way.
1) Provide a patch and see if it is accepted.
2) Convince somebody else that they should put time into features of questionable value such as this one.
mark
Quoted 76 lines · Elladan
I went to google and attempted to find information about the root reserve space for ext2, as a user wondering about the feature would. I couldn't find any documentation that states it's purely a fragmentation and convenience feature. I did, however, find documents stating otherwise. Note how even
Documentation/filesystems/ext2.txtstates that it's a security feature?If this is not a security feature,
Documentation/filesystems/ext2.txtneeds to be changed. Eg.,"In ext2, there is a mechanism for reserving a certain number of blocks for a particular user (normally the super-user). This is intended to keep the filesystem from filling up entirely, which helps combat fragmentation. The super-user may still use this space. Note that this is not a security feature, and is only provided for convenience - various methods exist where a user may circumvent this reservation and use the space if they so wish. Quotas or separate filesystems should be used if reliable space limits are needed."
1. http://web.mit.edu/tytso/www/linux/ext2intro.html
Design and Implementation of the Second Extended Filesystem
[....] Ext2fs reserves some blocks for the super user (root). Normally, 5% of the blocks are reserved. This allows the administrator to recover easily from situations where user processes fill up filesystems.
2.
Documentation/filesystems/ext2.txtReserved Space
--------------In ext2, there is a mechanism for reserving a certain number of blocks for a particular user (normally the super-user). This is intended to allow for the system to continue functioning even if non-priveleged users fill up all the space available to them (this is independent of filesystem quotas). It also keeps the filesystem from filling up entirely which helps combat fragmentation.
3. Note what mke2fs prints:
3275 blocks (5.00%) reserved for the super user
It does not say "reserved to combat fragmentation"
-J
Quoted 12 lines · Christoph Hellwig
Quoted 6 lines · Elladan
Quoted 3 lines
It is _not_ a security feature, it is meant to keep the filesystem from fragmenting too badly. root can use that space, since root can do whatever she wants anyway.
But it *appears* to be a security feature. Thus, someone might incorrectly depend on it, unless it's clearly documented as otherwise.
So what. People rely on
chroot()as security feature all the time and we don't "fix" it either. If you need security nothing but gaining knowledge about all details helps.Quoted 5 lines
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Quoted 2 lines · Mark Mielke
1) You can always submit a patch, and see whether other people approve of it.
I might decide to do that. But I wouldn't spend the time without first knowing if:
a) There were some very good reasons not to change it.
b) Somebody knowing this code by heart could write a patch in five minutes.
Quoted 4 lines
2) If you won't do it, why would somebody else working on something that provides lower latency to user process response time, or improvement to the IDE drivers, take the time to deal with this issue?
I don't intend to try to force somebody to do it, if they have more important things to do.
Quoted 5 lines
As it is, there are plenty of other denial-of-service type attacks that can be performed that would be more effective than the 'exploit' you have mentioned. Your proposal would need to be 'fix them all', if your complaint is that Linux has a security hole.
It surely would be nice to prevent all DoS attacks. But of course that would require a lot of work. However I think most other DoS attacks could be solved by a reboot.
Quoted 5 lines
If you complaint is that an administrator might mistakenly believe that it is a security feature, I suggest your understand that this is merely one issue of quite a few. If the administrator is not aware of issues such as these, perhaps they should not be an administrator?
We cannot blame administrators before the documentation has been changed.
Signature · 2 lines
Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:[email protected]
Hi!
Quoted 9 lines
I went to google and attempted to find information about the root reserve space for ext2, as a user wondering about the feature would. I couldn't find any documentation that states it's purely a fragmentation and convenience feature. I did, however, find documents stating otherwise. Note how even
Documentation/filesystems/ext2.txtstates that it's a security feature?If this is not a security feature,
Documentation/filesystems/ext2.txtneeds to be changed. Eg.,
I'd suggest you to mail to [email protected]; it sounds like security hole to me, and probably common across many unix variants.
Pavel
Signature · 2 lines
(about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Quoted 5 lines
Quoted 2 lines
If this is not a security feature,
Documentation/filesystems/ext2.txtneeds to be changed. Eg.,I'd suggest you to mail to [email protected]; it sounds like security hole to me, and probably common across many unix variants.
The original Unix documentation for FFS refers to it only as a performance oriented reason.
Alan
On Sun, May 12, 2002 at 11:37:30AM -0700, Elladan wrote:
...
Ok, thanks for the explanation earlier in the thread. I was mistaken.
Quoted 4 lines
Regardless of whether it's a good thing to depend on security-wise, it is a problem to have something that appears to be a security feature which doesn't actually work.
...
Quoted 1 line
Having unsupported security features is typically a bad idea.
I guess the point is that it is not a security feature.
The 5% default is good for ext2, since the filesystem will get heavily fragmented if you fill it up more than ~95%. So it is a convenience feature.
Signature · 6 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............:
Quoted 6 lines · Jakob Østergaard
Quoted 1 line · Elladan
Having unsupported security features is typically a bad idea.
I guess the point is that it is not a security feature.
The 5% default is good for ext2, since the filesystem will get heavily fragmented if you fill it up more than ~95%. So it is a convenience feature.
I would place it as 'system crash avoidance' rather than 'convenience' or 'security'.
If somebody purposefully tries to circumvent the 'system crash avoidance' feature, well... they could just as easily have said "while (1) fork;" and accomplished something similar.
mark
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/