Hapi: Security Notice & Bug Bounty - Path traversal via Symlink - huntr.dev

[huntr-helper]

This issue has been generated on-behalf of vineetpandey (https://huntr.dev/app/users/vineetpandey)

With a symbolically linked file in the working directory, it is possible to read arbitrary files outside of the web root directory.

PoC:

1. Install hapi: npm i @hapi/hapi
2. Run the server as: node static_server.js.

// static_server.js
const Path = require('path');
const Hapi = require('@hapi/hapi');
const Inert = require('@hapi/inert');
const init = async () => {

    const server = new Hapi.Server({
        host: 'localhost',
        port: 3000,
        routes: {
            files: {
                relativeTo: Path.join(__dirname, '.')
            }
        }
    });

    await server.register(Inert);

    server.route({
        method: 'GET',
        path: '/{param*}',
        handler: {
            directory: {
                path: '.',
                redirectToSlash: true
            }
        }
    });

    await server.start();

    console.log('Server running at:', server.info.uri);
};

init();

1. Create a symlink file within the directory ln -s /etc/shadow test_shadow.html
2. Request the file within browser http://localhost:3000/test_shadow.html

Bug Bounty

We have opened up a bounty for this issue on our bug bounty platform. Want to solve this vulnerability and get rewarded 💰? Go to https://huntr.dev/

We will submit a pull request directly to your repository with the fix as soon as possible. Want to learn more? Go to https://github.com/418sec/huntr 📚

_Automatically generated by @huntr-helper..._

[AdamGold]

Hey 👋 Adam from Snyk here. How is this a vulnerability? If a server's admin wishes to expose a secret file - Too bad. Can't see a way for this package to prevent this from happening?

[YoannMa]

@AdamGold They explained a bit why they think it's a vulnerability here : https://github.com/418sec/huntr/pull/50#pullrequestreview-435292902

(found it by digging a bit the repository)

[adam-nygate]

Also a bit more context at https://github.com/418sec/huntr/pull/158 (there was an issue with the original PR)

[Marsup]

While you're there, may I ask what's your policy about responsible disclosure? I couldn't find any on your website.

[AdamGold]

@adam-nygate So I'm having a hard time understanding your take on this. The way I see it, if an attacker has enough permissions to create a symlink to a secret file, then he/she wouldn't need the help of this package to access this file anyway. Therefore, this issue wouldn't help in a chain of exploitation nor would it help in a single exploitation.
I feel like the option to NOT follow symlinks is merely a feature rather than a security issue.

[adam-nygate]

@adam-nygate So I'm having a hard time understanding your take on this. The way I see it, if an attacker has enough permissions to create a symlink to a secret file, then he/she wouldn't need the help of this package to access this file anyway. Therefore, this issue wouldn't help in a chain of exploitation nor would it help in a single exploitation.

Given the unpredictable nature of developers who may use a package in a variety of ways, I think it's difficult to surmise presumptions of scenarios which may or may not lead to exploitation.
This GitHub Issue provokes discussion around this issue and whether this is intended behaviour, or if by default the package should treat symlinks cautiously by default (and allow administrators to override this behaviour via a flag - similar to what @toufik-airane said regarding nginx).

I understand that your systems may have 🚨 alarms going because we used _security_ in the title, but perhaps we should be encouraging open discussion about security within the open source community, and not try to stymie it.

[adam-nygate]

I feel like the option to NOT follow symlinks is merely a feature rather than a security issue.

Features and security controls are not mutually exclusive

[cjihrig]

I would expect a group focusing on security to follow responsible disclosure, as @Marsup pointed out.

perhaps we should be encouraging open discussion about security within the open source community, and not try to stymie it.

Open discussion about security is much different from publicly disclosing a potential vulnerability with reproducible code. This is very bad form on your part.

We will discuss this amongst the team and provide a response soon.

[AdamGold]

@adam-nygate So I'm having a hard time understanding your take on this. The way I see it, if an attacker has enough permissions to create a symlink to a secret file, then he/she wouldn't need the help of this package to access this file anyway. Therefore, this issue wouldn't help in a chain of exploitation nor would it help in a single exploitation.

Given the unpredictable nature of developers who may use a package in a variety of ways, I think it's difficult to surmise presumptions of scenarios which may or may not lead to exploitation.
This GitHub Issue provokes discussion around this issue and whether this is intended behaviour, or if by default the package should treat Symlinks cautiously by default (and allow administrators to override this behaviour via a flag - similar to what @toufik-airane said regarding nginx).

I understand that your systems may have 🚨 alarms going because we used _security_ in the title, but perhaps we should be encouraging open discussion about security within the open source community, and not try to stymie it.

Definitely not trying to stifle any conversation here 😄 These calls can be subjective, but we can only understand approaches if we chat about them, which is what I'm trying to do.

[devinivy]

Just to briefly follow-up on @cjihrig's comment— when you go to file an issue in this repository there is an option for "Report a security vulnerability", and it directs you not to a page to create a new issue, but to our security policy, which is clear about how we want to handle this kind of situation:

If you are not sure, don’t worry. Better safe than sorry – just send an email. Do not open issues related to any security concerns publicly. Please do not include anyone else on the disclosure email.

Regardless of whether you disagree with that, it would be appreciated if you would respect our wishes. If there is any chatter in here arguing about what constitutes responsible disclosure then those comments will be marked as off-topic.

[adam-nygate]

Removed as per @devinivy's comment

[adam-nygate]

@adam-nygate So I'm having a hard time understanding your take on this. The way I see it, if an attacker has enough permissions to create a symlink to a secret file, then he/she wouldn't need the help of this package to access this file anyway. Therefore, this issue wouldn't help in a chain of exploitation nor would it help in a single exploitation.

Given the unpredictable nature of developers who may use a package in a variety of ways, I think it's difficult to surmise presumptions of scenarios which may or may not lead to exploitation.
This GitHub Issue provokes discussion around this issue and whether this is intended behaviour, or if by default the package should treat Symlinks cautiously by default (and allow administrators to override this behaviour via a flag - similar to what @toufik-airane said regarding nginx).
I understand that your systems may have 🚨 alarms going because we used _security_ in the title, but perhaps we should be encouraging open discussion about security within the open source community, and not try to stymie it.

Definitely not trying to stifle any conversation here 😄 These calls can be subjective, but we can only understand approaches if we chat about them, which is what I'm trying to do.

Appreciate that @AdamGold - so that we don't flood this issue any further, feel free to reach out to me at [email protected] any time 😊 or for anyone else if they'd like to discuss thoughts on full disclosure

[nlf]

So I have a few points I want to address.

1. As has been mentioned by others, public disclosure with code to reproduce is not responsible. We have a policy that states how security findings should be communicated, and even if we didn't there are _no_ projects that appreciate having vulnerabilities displayed immediately to the public. When you disclose a vulnerability publicly and include code to reproduce it, you have now put every user of that module at risk. It is on you, the research team, to do better than that. We do security research on open source products to make them better, not to create turbulence.

2. The actual finding here is not a security vulnerability. If you place a file in a directory that you're making public, it is a reasonable assumption to make that you intended for that file to be public. Yes, we follow the symlink, but the user has to have placed the symlink there in the first place. To speak to the example you give, an attacker who is capable of creating the symlink is equally capable of copying the entire file and making it public that way. We cannot prevent users from making files public that should not be public, they have to make that decision for themselves.

3. While this is not a security finding, and not a vulnerability to patch, we do agree that an option to disable following symlinks is a reasonable feature request. I have opened one in the relevant repo here: https://github.com/hapijs/inert/issues/147

I am going to close and lock this issue at this time to discourage further conversation on this topic. If you'd like to follow up, feel free to send me an email to [email protected]