Please double check they are actually included in the distributed release.

Double checked. If I am right, I've found them in the official installation package, and they are still there at the end of the installation wizard.

Everything in libraries/vendor is pulled in via Composer and is essentially
third party code, including the Framework files. The Framework doesn't
require these defines as the code is typically installed outside the web
root and this check isn't required there. Otherwise, Joomla would have to
modify all external library code (anything not written and maintained in
the CMS repo) to add these checks.

On Thursday, January 21, 2016, Demis Palma notifications@github.com wrote:

A lot of Joomla libraries, lack the _JEXEC or die() check

According to the official documentation https://docsjoomlaorg/JEXEC,
those file should be protected:

if you access a file directly [] and a PHP error is raised (presuming your
PHP error reporting is set to show errors by default) [] then the file
needs to be protected

The most of the unprotected libraries, actually generate PHP errors,
causing the path exposure described in the documentation cited

For example the URL:
http://YOURSITE/libraries/vendor/joomla/application/src/Cli/Output/Stdoutphp
causes:

Fatal error: Class 'Joomla\Application\Cli\CliOutput' not found in
/home/user1250/www/libraries/vendor/joomla/application/src/Cli/Output/Stdoutphp
on line 19

I've found 59 unprotected files, but they might be more

libraries/vendor/joomla/application/src (4 usages found)
AbstractApplicationphp (1 usage found)
(9: 1) namespace Joomla\Application;
AbstractCliApplicationphp (1 usage found)
(9: 1) namespace Joomla\Application;
AbstractDaemonApplicationphp (1 usage found)
(9: 1) namespace Joomla\Application;
AbstractWebApplicationphp (1 usage found)
(9: 1) namespace Joomla\Application;
libraries/vendor/joomla/application/src/Cli (3 usages found)
CliOutputphp (1 usage found)
(9: 1) namespace Joomla\Application\Cli;
ColorProcessorphp (1 usage found)
(9: 1) namespace Joomla\Application\Cli;
ColorStylephp (1 usage found)
(9: 1) namespace Joomla\Application\Cli;
libraries/vendor/joomla/application/src/Cli/Output (2 usages found)
Stdoutphp (1 usage found)
(9: 1) namespace Joomla\Application\Cli\Output;
Xmlphp (1 usage found)
(9: 1) namespace Joomla\Application\Cli\Output;
libraries/vendor/joomla/application/src/Cli/Output/Processor (2 usages found)
ColorProcessorphp (1 usage found)
(9: 1) namespace Joomla\Application\Cli\Output\Processor;
ProcessorInterfacephp (1 usage found)
(9: 1) namespace Joomla\Application\Cli\Output\Processor;
libraries/vendor/joomla/application/src/Web (1 usage found)
WebClientphp (1 usage found)
(9: 1) namespace Joomla\Application\Web;
libraries/vendor/joomla/di/src (4 usages found)
Containerphp (1 usage found)
(9: 1) namespace Joomla\DI;
ContainerAwareInterfacephp (1 usage found)
(9: 1) namespace Joomla\DI;
ContainerAwareTraitphp (1 usage found)
(9: 1) namespace Joomla\DI;
ServiceProviderInterfacephp (1 usage found)
(9: 1) namespace Joomla\DI;
libraries/vendor/joomla/di/src/Exception (1 usage found)
DependencyResolutionExceptionphp (1 usage found)
(9: 1) namespace Joomla\DI\Exception;
libraries/vendor/joomla/event/src (10 usages found)
AbstractEventphp (1 usage found)
(9: 1) namespace Joomla\Event;
DelegatingDispatcherphp (1 usage found)
(9: 1) namespace Joomla\Event;
Dispatcherphp (1 usage found)
(9: 1) namespace Joomla\Event;
DispatcherAwareInterfacephp (1 usage found)
(9: 1) namespace Joomla\Event;
DispatcherInterfacephp (1 usage found)
(9: 1) namespace Joomla\Event;
Eventphp (1 usage found)
(9: 1) namespace Joomla\Event;
EventImmutablephp (1 usage found)
(9: 1) namespace Joomla\Event;
EventInterfacephp (1 usage found)
(9: 1) namespace Joomla\Event;
ListenersPriorityQueuephp (1 usage found)
(9: 1) namespace Joomla\Event;
Priorityphp (1 usage found)
(9: 1) namespace Joomla\Event;
libraries/vendor/joomla/filter/src (2 usages found)
InputFilterphp (1 usage found)
(9: 1) namespace Joomla\Filter;
OutputFilterphp (1 usage found)
(9: 1) namespace Joomla\Filter;
libraries/vendor/joomla/input/src (5 usages found)
Cliphp (1 usage found)
(9: 1) namespace Joomla\Input;
Cookiephp (1 usage found)
(9: 1) namespace Joomla\Input;
Filesphp (1 usage found)
(9: 1) namespace Joomla\Input;
Inputphp (1 usage found)
(9: 1) namespace Joomla\Input;
Jsonphp (1 usage found)
(9: 1) namespace Joomla\Input;
libraries/vendor/joomla/registry/src (2 usages found)
AbstractRegistryFormatphp (1 usage found)
(9: 1) namespace Joomla\Registry;
Registryphp (1 usage found)
(9: 1) namespace Joomla\Registry;
libraries/vendor/joomla/registry/src/Format (5 usages found)
Iniphp (1 usage found)
(9: 1) namespace Joomla\Registry\Format;
Jsonphp (1 usage found)
(9: 1) namespace Joomla\Registry\Format;
Phpphp (1 usage found)
(9: 1) namespace Joomla\Registry\Format;
Xmlphp (1 usage found)
(9: 1) namespace Joomla\Registry\Format;
Yamlphp (1 usage found)
(9: 1) namespace Joomla\Registry\Format;
libraries/vendor/joomla/session/Joomla/Session (2 usages found)
Sessionphp (1 usage found)
(9: 1) namespace Joomla\Session;
Storagephp (1 usage found)
(9: 1) namespace Joomla\Session;
libraries/vendor/joomla/session/Joomla/Session/Storage (7 usages found)
Apcphp (1 usage found)
(9: 1) namespace Joomla\Session\Storage;
Databasephp (1 usage found)
(9: 1) namespace Joomla\Session\Storage;
Memcachephp (1 usage found)
(9: 1) namespace Joomla\Session\Storage;
Memcachedphp (1 usage found)
(9: 1) namespace Joomla\Session\Storage;
Nonephp (1 usage found)
(9: 1) namespace Joomla\Session\Storage;
Wincachephp (1 usage found)
(9: 1) namespace Joomla\Session\Storage;
Xcachephp (1 usage found)
(9: 1) namespace Joomla\Session\Storage;
libraries/vendor/joomla/string/src (3 usages found)
Inflectorphp (1 usage found)
(9: 1) namespace Joomla\String;
Normalisephp (1 usage found)
(9: 1) namespace Joomla\String;
Stringphp (1 usage found)
(9: 1) namespace Joomla\String;
libraries/vendor/joomla/uri/src (5 usages found)
AbstractUriphp (1 usage found)
(9: 1) namespace Joomla\Uri;
Uriphp (1 usage found)
(9: 1) namespace Joomla\Uri;
UriHelperphp (1 usage found)
(9: 1) namespace Joomla\Uri;
UriImmutablephp (1 usage found)
(9: 1) namespace Joomla\Uri;
UriInterfacephp (1 usage found)
(9: 1) namespace Joomla\Uri;
libraries/vendor/joomla/utilities/src (1 usage found)
ArrayHelperphp (1 usage found)
(9: 1) namespace Joomla\Utilities;

—
Reply to this email directly or view it on GitHub
#8957.

The Framework doesn't
require these defines as the code is typically installed outside the web
root and this check isn't required there.

But if they are included here then they are in the web root and do reveal an information disclosure. Do these src folders need to be included with the CMS?

Yes. There are bits and pieces of the Framework code in use in the CMS, and stuff that isn't in direct use is pulled in as a dependency (i.e. the Joomla\Filter classes are a dependency of Joomla\Input which is a dependency of Joomla\Application, only the latter namespace has any direct use in the CMS at the moment). The options basically are impose the define requirement on the Framework which would break any use of the existing code out there, the CMS hacks all third party files to include this define (including PHPMailer, the password_hash() polyfill, SimplePie, etc.), or just drop the Framework code. Personal opinion, anything that's pulled as an outside dependency (more clearly marked today by the fact almost all of them live in libraries/vendor) shouldn't be touched. PHPMailer, SimplePie, and others don't have the defined or die check in place, what makes the Framework's code a special case?

FWIW, it isn't just Joomla code that will trigger this. Any third party library code which extends another class or implements an interface will do the trick.

3.4.8:

• libraries/vendor/symfony/yaml/Symfony/Component/Yaml/Exception/DumpException.php
• libraries/vendor/psr/log/Psr/Log/AbstractLogger.php

EDIT: And libraries/vendor/psr/log/Psr/Log/LoggerAwareTrait.php would probably throw parser errors on PHP 5.3 since traits are a PHP 5.4 feature.

@mbabker my opinion follows

what makes the Framework's code a special case?

I agree. Framework and third party libraries are not a special case. They must therefore respect the general rule, with no exceptions.
The rule states that those files must be protected with the _JEXEC check.

The fact that files are classified as Framework, or third party, does not mitigate the information exposure.
Extensions on the JED may be unpublished due to directory information disclosure, or the lack of the _JEXEC check.

anything that's pulled as an outside dependency [...] shouldn't be touched.

You say that because a path disclosure is a small security risk, but would you be willing to sustain this argument in case of a third party library was vulnerable to an SQL injection?

I agree. Framework and third party libraries are not a special case. They must therefore respect the general rule, with no exceptions.
The rule states that those files must be protected with the _JEXEC check.

So do you agree then that we should be hacking classes and interfaces that have been pulled in from Symfony and PHP-FIG (Psr namespace) with these checks? We preach about not core hacking, yet the suggestion here equates to core hacking third party libraries (something Joomla has a history of sadly, see the password_hash() polyfill when it was shipped in 3.2 and the current Bootstrap offering).

Does the JED mandate that third party libraries must be altered to include the defined or die check?

You say that because a path disclosure is a small security risk, but would you be willing to sustain this argument in case of a third party library was vulnerable to an SQL injection?

Depends. Is the library still maintained? If so, has the maintainer been informed, or has Joomla contributed details to the maintainer to assist in patching said hole? If it is not maintained, as is the case with the phputf8 library that the JString classes wrap, then Joomla should be patching said hole and be looking for a maintained solution to replace it or fork and integrate that library into its code stack properly and stop treating it as an external dependency.

If it's Joomla's stance that third party code should be manipulated in ANY form for ANY reason, IMO the only responsible actions are to discontinue consuming third party code and to migrate all third party libraries to home-grown code written by members of the Joomla community.

We certainly are not going to change 3rd party classes to add JEXEC checks. That would be insane.

What we could probably do is restrict access to the vendor folder in our default htaccess.txt file. I doubt anything in there is supposed to be accessed directly by the browser. So people using our proposed ,htaccess rules would be safe from that. Someone with more knowledge about htaccess rules may comment on that.

Htacces isn't a solution while we support IIS.

Do we need to ship the vendor/src?
On 22 Jan 2016 2:51 pm, "Thomas Hunziker" notifications@github.com wrote:

We certainly are not going to change 3rd party classes to add JEXEC
checks. That would be insane.

What we could probably do is restrict access to the vendor folder in our
default htaccess.txt file. I doubt anything in there is supposed to be
accessed directly by the browser. So people using our proposed ,htaccess
rules would be safe from that. Someone with more knowledge about htaccess
rules may comment on that.

—
Reply to this email directly or view it on GitHub
#8957 (comment).

In my opinion, if they were dependencies, you would simply impose a dependency constraints (that is: before install Joomla, please ensure that you have installed PHP5.3, PHPMailer, and so on...)
On the contrary, the fact that the libraries are distributed with Joomla can be considered a fork. There is nothing bad editing files forked.

However, this is not the matter.
Whatever you want to call it, if we distribute those files, we have the responsibility over them.
Information disclosures like this one, has already happened in past, and they were classified as severity "5" in a scale from 0 to 9.

Htacces isn't a solution while we support IIS.

To my knowledge IIS has a similar file called web.config. But I don't know what can be done with it.

Do we need to ship the vendor/src?

Yes, it contains all the 3rd party code we use in our CMS. So dropping that would break the whole CMS

@Bakual
NGINX Does not support .htaccess, web.config or similar.

I'm sure there are also ways to protect a directory with NGINX.

I thought we used the code in /vendor not /vendor/src - mea culpa

I'm sure there are also ways to protect a directory with NGINX.

Yes, they exist at the service configuration level. You can't change that configuration at run time with a configuration file. It's one of the main advantages that makes NGINX so fast ad safe.

I thought we used the code in /vendor not /vendor/src - mea culpa

There is no /vendor/src. There is /vendor/.../.../src (eg libraries/vendor/joomla/application/src). I thought you referred to those folders

Yes, they exist at the service configuration level. You can't change that configuration at run time with a configuration file. It's one of the main advantages that makes NGINX so fast ad safe.

I understand that. But to my knowledge you also have to change that config for the SEF rewrite rules. So you need to take the htaccess.txt and convert it to NGINX config anyway. We don't ship a template for that. You would just have to copy/convert one rule more.

In nginx, it needs to be added to global server/host config, there is no htaccess or web config.

So, if there is no need to direct uri access, it would be something like this:
Example:

location /libraries/ { return 404; }

Just for reference, here's the stuff in the vendor folder that isn't really needed for the CMS:

• libraries/vendor/joomla/di - Unused at present by the CMS (dependency injection container, extensions are running it though)
• libraries/vendor/joomla/event - Unused by the CMS (inherent dependency of joomla/session package)
• libraries/vendor/joomla/filter - Unused by the CMS (inherent dependency of joomla/application package)
• libraries/vendor/joomla/input - Unused by the CMS (inherent dependency of joomla/application package)
• libraries/vendor/joomla/session - Unused by the CMS (inherent dependency of joomla/application package)
• libraries/vendor/psr/log - Unused by the CMS (inherent dependency of joomla/application package)

The issue with dropping this code is then Joomla ships broken libraries

In my opinion, if they were dependencies, you would simply impose a dependency constraints (that is: before install Joomla, please ensure that you have installed PHP5.3, PHPMailer, and so on...)

As a distributed application, not an option. We're better off ditching the CMS and focusing 100% on the Framework if that's the case (that's the Framework's model, by way of how Composer and Packagist work).

Just for the fact that the libraries are distributed with Joomla it can be considered a fork. There is nothing bad editing files forked.

I would not say that at all. If I packaged Akeeba and some NoNumber extensions into my own quick start distro, does that mean I've forked those extensions because I've created my own distribution?

Whatever you want to call it, if we distribute those files, we have the responsibility over them.

I agree. As long as it does not include manipulating third party libraries. There are other ways to deal with this specific issue that doesn't require hacks and I would encourage those avenues be used over simply editing third party code and hoping people remember to apply the same hacks every time an update is performed.

@mbabker

does that mean I've forked those extensions because I've created my own distribution?

No, it doesn't. You are right: there's a deep difference between a fork and a distro.

What about servers which don't have option to enable rewrite rules? (It's not a requirement ATM just an option for SEO URLs)
We would not be able to secure these anyway in any way except by adding this _JEXEC or die(); check to each 3p file which is not really a solution IMHO.

The only real solution to this is to get anything out of the web root, that should not be browser-accessible. Just like every modern framework does.

Which is impossible on 99% of the web hosts used to host joomla sites.
On 29 Jan 2016 11:21 pm, "Niels Braczek" notifications@github.com wrote:

The only real solution to this is to get anything out of the web root,
that should not be browser-accessible. Just like every modern framework
does.

—
Reply to this email directly or view it on GitHub
#8957 (comment).

How about prefixing every request with public/ internally (.htaccess, web.config, host.config)?

Anything that relies on .htaccess (or nginx and IIS equivalents) being enabled by default or results in a directory tree restructure (to include moving everything out of the web root) with Joomla's current distribution model is a no-go. Because there are users installing Joomla on crap hosts that if they're lucky they get FTP access at the web root and no higher or the host has .htaccess directives disabled or some other crazy set of configurations that would just make Joomla look broken.

Which is impossible on 99% of the web hosts used to host joomla sites.

I want to see a proof of that. In the 20 years, I work on the web now, I've never come across a host, where I could not point the domain to a subdirectory of the webspace.

A subdirectory of the web space is INSIDE the web root. You said the solution was to install those libraries OUTSIDE of the web root. As I stated that is not something that is possible with the hosting joomla users have.

'Web root', as I use it, is the directory accessed through the URL '/'.

I stand by what i said then. You are assuming a site can be installed in a
subdirectory off of the web root and then mapped to / which is something
most shared hosts don't allow and even when allowed is beyond the users
skills as evidenced by the almost daily posts on the forum from users who
have installed joomla in /joomla and now want it to be mapped as /
On 30 Jan 2016 1:01 pm, "Niels Braczek" notifications@github.com wrote:

'Web root', as I use it, is the directory accessed through the URL '/'.

—
Reply to this email directly or view it on GitHub
#8957 (comment).

something most shared hosts don't allow
impossible on 99% of the web hosts

Still missing proof for that.

beyond the users skills

So the solution is to enforce everybody to do it wrong, because some seem to be incapable to do it right?

No point in debating. I live in the real world of joomla as a mass market
web site solution. You clearly do not.
On 30 Jan 2016 1:21 pm, "Niels Braczek" notifications@github.com wrote:

something most shared hosts don't allow
impossible on 99% of the web hosts
Still missing proof for that.

beyond the users skills
So the solution is to enforce everybody to do it wrong, because some
seem to be incapable to do it right?

—
Reply to this email directly or view it on GitHub
#8957 (comment).

That's not helpful. Just a thought-terminating cliché. You still owe an evidence.

I am following your own advice
On 30 Jan 2016 1:31 pm, "Niels Braczek" notifications@github.com wrote:

That's not helpful. Just a thought-terminating cliché. You still owe an
evidence.

—
Reply to this email directly or view it on GitHub
#8957 (comment).

Can we please stop debating things that never can go into 3.x due to B/C issues and start evaluating real solutions?
Moving files out of web root is something that can be elabroated with J4, but not with J3.
And especially also stop attacking eachother. Thanks.

evaluating real solutions

That's what I'm trying to do.

Moving files out of web root is something that can be elabroated with J4, but not with J3.

Agree. But the milestone for solving the issue does not matter, IMHO.

stop attacking eachother

It wasn't my intention to attack anyone. I just want to see a proof for the claim raised in the discussion.

Thanks @Bakual, to me the only affordable solution in the short time is to add those damned _JEXEC checks.
Once done, we can discuss a better strategy for the long time.
I don't see solid reasons to refuse editing those files.

I know that adding the same instructions at the top of each file is a brain-less activity, but it can be done by a computer through a script, (with due care and considerations) rather by a human.

Agreed. Makes no sense not to. We do it for other things and force all
extensions to do it.
On 30 Jan 2016 2:02 pm, "Demis Palma" notifications@github.com wrote:

Thanks @Bakual https://github.com/Bakual, to me the only affordable
solution in the short time is to add those damned _JEXEC checks.
Once done, we can discuss a better strategy for the long time.
I don't see solid reasons to refuse editing those files.

I know that adding the same instructions at the top of each file is a
brain-less activity, but it can be done by a computer through a script,
rather by a human.

—
Reply to this email directly or view it on GitHub
#8957 (comment).

So the mentality is that Joomla enforces ALL third party code to be hacked? To every one of you who talks down on users who core hack, you can no longer do that.

I also recommend IMMEDIATELY that replacement libraries for Symfony's YAML component, the password_hash() polyfill, the random_bytes() polyfill, Symfony's PHP 5.6 polyfill, PHPMailer, IDNA Convert, PHPass, the PSR-3 Logging interface, the LESS compiler, and Composer be implemented using code written by members of the Joomla community willing to contribute these libraries to the Joomla core project. I also recommend IMMEDIATELY that the JED enforce a no-third-party requirement on all extensions. This bold statement (mandating third party code is core hacked) means Joomla CANNOT accept ANY code from an external vendor in its operating space.

EDIT: Added a couple other packages.

I'm closing this and locking to prevent more stupid messages.

We will not be changing composer imported files in any way. Period.
If you want to discuss Joomla 4 folder layouts (which I believe was decided by the group last week anyhow) please do that in the relevant glip group. Thanks.