Steps to reproduce:
1) Upload a PHP script to the Media Libray,
naming it "test" (or any other name
without extension).
2) Rename it to "exploit.php." (trailing dot!)
On Linux, the file will be renamed to
"exploit.php..", which is safe and
cannot be exploited.
On Windows though, the file will be
renemad to "exploit.php" and is then
remotely executable by calling it
from "/uploads/exploit.php".
Thanks to Junyu Zhang <rgdz.eye@gmail.com>
for spotting this!
Signed-off-by: Thomas Hochstein <thh@inter.net>
After fixing the other ML file renaming bugs,
it was now possible to rename a file without
extension into a file that *does* have an
extension - so we need to check against
active content.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The renaming code added a dot '.' to the
filename on disk even if the file hat no
extension. Therefore, the file name on disk was
different from the name in the database,
triggering the database purging code on the
next ML display.
(serendipity_displayImageList() will delete
files from the database that don't exist
any longer on disk.)
This code won't add spurious dots for
empty extensions, keeping disk and
database in sync.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Completing 1ed4b9e7eca2a0c371582a454c232c
As we already have an (unused) language
constant for this error, we seem to have
had this kind of check before ...
Signed-off-by: Thomas Hochstein <thh@inter.net>
* plugin_api.inc.php:
- Add static list of bundled plugins.
- Add function to check if plugin is
bundled.
* plugins.inc.php:
- Set source of plugin
(Spartacus, bundled or local).
* plugins.inc.tpl:
- Display plugin source.
* Add language constants.
Signed-off-by: Thomas Hochstein <thh@inter.net>
When installing / updating plugins, plugin data
is fetched from Spartacus first; those plugins
will habe "Spartacus" as "pluginlocation".
Later on, information about installed plugins
is fetched from cache / database, overwriting
the previously fetched data for all installed
plugins. After that, "pluginlocation" is
"local" even for plugins that live on
Spartacus if they have been installed.
So we save "pluginlocation" data to a new
"pluginsource" field before merging /
overwriting so we can detect plugins that
are available on Spartacus.
This data is present in plugins.inc.tpl
and can be used there.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Note: Native to utf8 will not work if the data in the database table is actually utf8! These are helper functions for during the alpha, to make testing easier, not tasks for the beta/stable
utf8mb4 did not work on a test server with large prefix (=not 3000 byte index limit, only 1000) on Depian 9/mariadb 10.1.44, because the row format was not barracuda (by default?)
If $limit is empty(), no limit is set, so we can
set the LIMIT statement to "" to achieve the same.
But an empty() $limit can be "0", so the
generated SQL statement could end with "0"
instead of the LIMIT statement. We catch this
with forcing an empty() $limit to "".
Fixes#636.
(No matter that this shouldn't even happen.)
Signed-off-by: Thomas Hochstein <thh@inter.net>
When renaming objects in the Media Library,
s9y didn't check if a file with the same
name already exists, resulting in a file
name collision deleting both files from
the database _and_ from disk.
Add a check to avoid that.
An error message would be nice, too, but
that may be added later on.
Tested on s9y-stable test instance.
Signed-off-by: Thomas Hochstein <thh@inter.net>
s9y will encode the body of its auto-generated
mails as quoted-printable when imap_8bit() is
available. imap_8bit() will use "\r\n" as
linebreaks as mandated for SMTP transfer.
The result will be transmitted via PHP's
mail() function, using direct SMTP on
Windows and piping it to a MTA on Unix.
Most MTAs will cope just fine with those
linebreaks, while qmail will not; it will
replace all "\n" linebreaks with "\r\n",
so we get "\r\r\n" in our case. We can't
"fix" qmail (as its maintainer, if there
even is one, does not consider this
behaviour wrong), but we can replace the
line endings we get from imap_8bit().
The fix does work with qmail and Exim and
should work with sendmail and Postfix and
other MTAs, too. It may break sending
mail on Windows (i.e. lose all linebreaks),
but I think that's acceptable, as we'll
have more qmail installation than Windows
servers out there.
A workaround could be to set
serendipity['forceBase64']=true in
serendipity_config_local.inc.php, but I'd
prefer this fix.
Fixes#644.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The autologin ("Save information") functionality in 2.3.1 is broken since
commit 52a41b37d554da11acc932eeec44c5fb1414a492
CommitDate: Fri Mar 23 18:01:32 2018 +0100
Rework autologin to use a token approach
Although a cookie serendipity[author_autologintoken] with correct
expiration (one month) which random data content is present as value
in the serendipity_options table with name autologin_Username and
correct timestamp as okey and that is found with manually executing
the SQL statement
SELECT name, value, okey FROM serendipity_options WHERE name = 'autologin_Username' AND okey > 1565801743 LIMIT 1
like done in include/functions_config.inc.php
serendipity_checkAutologin(), the login is forgotten after 30 minutes
or so. That was not the case with 2.1.5 where the login was valid for
weeks.
Of
if (stristr($serendipity['dbType'], 'sqlite')) {
$cast = "okey";
} else {
// Adds explicits casting for mysql, postgresql and others.
$cast = "cast(okey as integer)";
}
from which $cast then is used in the SQL statement instead of a plain
okey; when doing that manually with
SELECT name, value, okey FROM serendipity_options WHERE name = 'autologin_Username' AND cast(okey as integer) > 1565801743 LIMIT 1
it produces the MySQL error
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'integer) > 1565801743 LIMIT 1' at line 1
This also with $serendipity['dbType'] = 'mysqli' for the above code.
Indeed, cast(okey as integer) is invalid in MySQL and should be
cast(okey as unsigned) instead which then also works manually, see
https://stackoverflow.com/a/12127022 and
https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_cast
Same in serendipity_issueAutologin().
Changing those two places accordingly resolves the autologin not
persistent problem.
Additionally, inspecting the serendipity_options table revealed loads
of old serendipity[author_authorinformation] cookie information that
was never deleted in serendipity_issueAutologin() with the
OR (okey LIKE 'l_%' AND $cast < " . (time() - 1814400) . ")")
expression producing a MySQL error. This has to be done manually
once as also 2.3.1 will not delete it anymore.
We shouldn't swap prev/next links for archive
pages. With stable archives, the title page is
the last page of the archive, not the first, so
all other pages are "previos", and we should
display it like that.
That may seem counterintuitive at first, but
otherwise archive page directions and pagination
directions don't match (see bulletproof), and we
shouldn't count archive pages differently from
the URL. With the current code, page 100 of 100
archive pages would be shown in footer_info as
page 1, page 99 as page 2, and that doesn't make
sense either.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The current page will always be the current page,
regardless of archive sorting order. Page 76 of
86 pages will remain page 76, even if the archive
sorting is changed; it won't become page 10.
Fixes#625 in core.
Themes will have to cope with the sorting order
in their pagination code if they want to display
a descending order for stable archive sorting.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Quite some information is missing from
the list of installed plugins; and the
list of installable plugins has some
more information, but not everything
that is present on Spartacus, i.e.
the last modification date.
So let's add a link to the plugin entry
on Spartacus (in the chosen language
version).
Fixes#471.
Signed-off-by: Thomas Hochstein <thh@inter.net>
"requirement_failures" from PHP is saved in
"requirements_failues" - "requirements" as
in plural, and with a typo. That doesn't make
sense. Let's use "requirement_failures"
everywhere.
Signed-off-by: Thomas Hochstein <thh@inter.net>
