What are the dangers of having writable chroot directory for FTP?
People around the net are all yelling how insecure it is to have writable root FTP directory, if you configure your FTP server with the chroot option (vsftpd won't even run).
I miss the explanation why is it bad?
Could someone expand a little bit more on that topic and explain what are the dangers, how a chroot directory writable by unprivileged users can be exploited?
permissions security ftp chroot
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
add a comment |
People around the net are all yelling how insecure it is to have writable root FTP directory, if you configure your FTP server with the chroot option (vsftpd won't even run).
I miss the explanation why is it bad?
Could someone expand a little bit more on that topic and explain what are the dangers, how a chroot directory writable by unprivileged users can be exploited?
permissions security ftp chroot
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
add a comment |
People around the net are all yelling how insecure it is to have writable root FTP directory, if you configure your FTP server with the chroot option (vsftpd won't even run).
I miss the explanation why is it bad?
Could someone expand a little bit more on that topic and explain what are the dangers, how a chroot directory writable by unprivileged users can be exploited?
permissions security ftp chroot
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
People around the net are all yelling how insecure it is to have writable root FTP directory, if you configure your FTP server with the chroot option (vsftpd won't even run).
I miss the explanation why is it bad?
Could someone expand a little bit more on that topic and explain what are the dangers, how a chroot directory writable by unprivileged users can be exploited?
permissions security ftp chroot
permissions security ftp chroot
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
edited Nov 17 '16 at 9:39
NarūnasK
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
asked Nov 16 '16 at 13:01
NarūnasKNarūnasK
8971622
8971622
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
- https://www.auscert.org.au/bulletins/15286/
- https://www.auscert.org.au/bulletins/15526/
In order to use the chroot(2) function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within /etc (or /lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real /etc/ and /lib directories on the system -- but within the chroot, these client-created files are real.
So the malicious client connects to an FTP server which chroots their process, they create the necessary /lib and /etc directories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.
Note that /etc and /lib are not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.
ProFTPD, for example, now bars the creation of such /etc/ and /lib directories when chrooted, to mitigate such attacks.
Hope this helps!
edited 8 mins ago
Clonkex
12316
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
2
Why would the FTP server default to using libraries contained within the chroot?
– Martin Konecny
Aug 18 '17 at 15:11
It is not the server which uses the libraries, necessarily; most times, it is the C library routines which dynamically load libraries from "well known locations" (such as from/etc/or/lib/). Think ofgethostbyname(3)automatically reading/etc/hostsor/etc/resolv.conf;getpwnam(3)might use NSS, and thus read/etc/nsswitch.confand related NSS libraries.
– Castaglia
Aug 18 '17 at 15:13
I'm more curious why the FTP server wouldn't just fake chroot. It's not really that hard.
– Wayne Werner
Oct 3 '18 at 20:33
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f323711%2fwhat-are-the-dangers-of-having-writable-chroot-directory-for-ftp%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
- https://www.auscert.org.au/bulletins/15286/
- https://www.auscert.org.au/bulletins/15526/
In order to use the chroot(2) function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within /etc (or /lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real /etc/ and /lib directories on the system -- but within the chroot, these client-created files are real.
So the malicious client connects to an FTP server which chroots their process, they create the necessary /lib and /etc directories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.
Note that /etc and /lib are not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.
ProFTPD, for example, now bars the creation of such /etc/ and /lib directories when chrooted, to mitigate such attacks.
Hope this helps!
edited 8 mins ago
Clonkex
12316
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
2
Why would the FTP server default to using libraries contained within the chroot?
– Martin Konecny
Aug 18 '17 at 15:11
It is not the server which uses the libraries, necessarily; most times, it is the C library routines which dynamically load libraries from "well known locations" (such as from/etc/or/lib/). Think ofgethostbyname(3)automatically reading/etc/hostsor/etc/resolv.conf;getpwnam(3)might use NSS, and thus read/etc/nsswitch.confand related NSS libraries.
– Castaglia
Aug 18 '17 at 15:13
I'm more curious why the FTP server wouldn't just fake chroot. It's not really that hard.
– Wayne Werner
Oct 3 '18 at 20:33
add a comment |
The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
- https://www.auscert.org.au/bulletins/15286/
- https://www.auscert.org.au/bulletins/15526/
In order to use the chroot(2) function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within /etc (or /lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real /etc/ and /lib directories on the system -- but within the chroot, these client-created files are real.
So the malicious client connects to an FTP server which chroots their process, they create the necessary /lib and /etc directories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.
Note that /etc and /lib are not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.
ProFTPD, for example, now bars the creation of such /etc/ and /lib directories when chrooted, to mitigate such attacks.
Hope this helps!
edited 8 mins ago
Clonkex
12316
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
2
Why would the FTP server default to using libraries contained within the chroot?
– Martin Konecny
Aug 18 '17 at 15:11
It is not the server which uses the libraries, necessarily; most times, it is the C library routines which dynamically load libraries from "well known locations" (such as from/etc/or/lib/). Think ofgethostbyname(3)automatically reading/etc/hostsor/etc/resolv.conf;getpwnam(3)might use NSS, and thus read/etc/nsswitch.confand related NSS libraries.
– Castaglia
Aug 18 '17 at 15:13
I'm more curious why the FTP server wouldn't just fake chroot. It's not really that hard.
– Wayne Werner
Oct 3 '18 at 20:33
add a comment |
The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
- https://www.auscert.org.au/bulletins/15286/
- https://www.auscert.org.au/bulletins/15526/
In order to use the chroot(2) function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within /etc (or /lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real /etc/ and /lib directories on the system -- but within the chroot, these client-created files are real.
So the malicious client connects to an FTP server which chroots their process, they create the necessary /lib and /etc directories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.
Note that /etc and /lib are not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.
ProFTPD, for example, now bars the creation of such /etc/ and /lib directories when chrooted, to mitigate such attacks.
Hope this helps!
edited 8 mins ago
Clonkex
12316
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
- https://www.auscert.org.au/bulletins/15286/
- https://www.auscert.org.au/bulletins/15526/
In order to use the chroot(2) function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within /etc (or /lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real /etc/ and /lib directories on the system -- but within the chroot, these client-created files are real.
So the malicious client connects to an FTP server which chroots their process, they create the necessary /lib and /etc directories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.
Note that /etc and /lib are not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.
ProFTPD, for example, now bars the creation of such /etc/ and /lib directories when chrooted, to mitigate such attacks.
Hope this helps!
edited 8 mins ago
Clonkex
12316
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
edited 8 mins ago
Clonkex
12316
edited 8 mins ago
Clonkex
12316
edited 8 mins ago
Clonkex
12316
12316
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
answered Dec 24 '16 at 18:21
CastagliaCastaglia
4011411
4011411
2
Why would the FTP server default to using libraries contained within the chroot?
– Martin Konecny
Aug 18 '17 at 15:11
It is not the server which uses the libraries, necessarily; most times, it is the C library routines which dynamically load libraries from "well known locations" (such as from/etc/or/lib/). Think ofgethostbyname(3)automatically reading/etc/hostsor/etc/resolv.conf;getpwnam(3)might use NSS, and thus read/etc/nsswitch.confand related NSS libraries.
– Castaglia
Aug 18 '17 at 15:13
I'm more curious why the FTP server wouldn't just fake chroot. It's not really that hard.
– Wayne Werner
Oct 3 '18 at 20:33
add a comment |
2
Why would the FTP server default to using libraries contained within the chroot?
– Martin Konecny
Aug 18 '17 at 15:11
It is not the server which uses the libraries, necessarily; most times, it is the C library routines which dynamically load libraries from "well known locations" (such as from/etc/or/lib/). Think ofgethostbyname(3)automatically reading/etc/hostsor/etc/resolv.conf;getpwnam(3)might use NSS, and thus read/etc/nsswitch.confand related NSS libraries.
– Castaglia
Aug 18 '17 at 15:13
I'm more curious why the FTP server wouldn't just fake chroot. It's not really that hard.
– Wayne Werner
Oct 3 '18 at 20:33
2
2
Why would the FTP server default to using libraries contained within the chroot?
– Martin Konecny
Aug 18 '17 at 15:11
Why would the FTP server default to using libraries contained within the chroot?
– Martin Konecny
Aug 18 '17 at 15:11
It is not the server which uses the libraries, necessarily; most times, it is the C library routines which dynamically load libraries from "well known locations" (such as from
/etc/ or /lib/). Think of gethostbyname(3) automatically reading /etc/hosts or /etc/resolv.conf; getpwnam(3) might use NSS, and thus read /etc/nsswitch.conf and related NSS libraries.– Castaglia
Aug 18 '17 at 15:13
It is not the server which uses the libraries, necessarily; most times, it is the C library routines which dynamically load libraries from "well known locations" (such as from
/etc/ or /lib/). Think of gethostbyname(3) automatically reading /etc/hosts or /etc/resolv.conf; getpwnam(3) might use NSS, and thus read /etc/nsswitch.conf and related NSS libraries.– Castaglia
Aug 18 '17 at 15:13
I'm more curious why the FTP server wouldn't just fake chroot. It's not really that hard.
– Wayne Werner
Oct 3 '18 at 20:33
I'm more curious why the FTP server wouldn't just fake chroot. It's not really that hard.
– Wayne Werner
Oct 3 '18 at 20:33
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f323711%2fwhat-are-the-dangers-of-having-writable-chroot-directory-for-ftp%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
