Gin-vue-admin is a backstage management system based on vue and gin, which separates the front and rear of the full stack. The problem occurs in the following code in server/service/system/sysautocodepgsql.go, which means that PostgreSQL must be used as the database for this vulnerability to occur. Users must: Require JWT login? and be using PostgreSQL to be affected. This issue has been resolved in version 2.5.1. There are no known workarounds.
The postgresql-ocaml bindings 1.5.4, 1.7.0, and 1.12.1 for PostgreSQL libpq do not properly support the PQescapeStringConn function, which might allow remote attackers to leverage escaping issues involving multibyte character encodings.
A race condition in the postgresql init script could be used by attackers able to access the postgresql account to escalate their privileges to root.
Description of problem: All currently shipped versions of PostgreSQL are vulnerable to a new type of attack pointed out by Gurjeet Singh. The scenario is similar to CVE-2007-6600 in that an attacker must be an authenticated user so that he can create a table with attached indexes, which reference functions he has created. Subsequent maintenance operations performed by database superusers will then have to execute those functions. In -6600 the threat was simply to acquire the caller's privileges directly. However, another possibility is that the index function can modify session-local state in a way that will subvert later operations in the same session. Examples include changing the searchpath so that an attacker-created function will be invoked instead of the intended one, or replacing an existing prepared statement with a new one containing code of the attacker's choosing. There have up to now been only very limited security controls on most session-local state, so it was easy to think of possible attack vectors once the basic issue was recognized.
This attack is less dangerous than -6600 since it only succeeds if the calling session does something subvert-able later. In particular it's not clear that there's any major risk for automatic vacuum operations. But superusers who do manual vacuuming or reindexing are clearly at risk.
Upstream versions due to be announced Monday 12-14 contain assorted fixes meant to mitigate this scenario.
PostgreSQL 7.4.x before 7.4.27, 8.0.x before 8.0.23, 8.1.x before 8.1.19, 8.2.x before 8.2.15, 8.3.x before 8.3.9, and 8.4.x before 8.4.2 does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which (1) allows man-in-the-middle attackers to spoof arbitrary SSL-based PostgreSQL servers via a crafted server certificate issued by a legitimate Certification Authority, and (2) allows remote attackers to bypass intended client-hostname restrictions via a crafted client certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.
Quoting upstream PostgreSQL security page: http://www.postgresql.org/support/security.html
Authenticated non-superusers can shut down the backend server by re-LOAD-ing libraries in $libdir/plugins, if any libraries are present there.
Affected versions: 8.4, 8.3, 8.2
Fixed in versions: 8.4.1, 8.3.8, 8.2.14
Severity: D - A vulnerability that is exploitable for denial-of-service, but requiring a valid prior login.
Quoting upstream PostgreSQL security page: http://www.postgresql.org/support/security.html
The fix for issue CVE-2007-2138 (below) failed to include protection against misuse of RESET SESSION AUTHORIZATION.
Affected versions: 8.4, 8.3, 8.2, 8.1, 8.0, 7.4 (note: this may affect previous 7.x versions too, but upstream does not support pre-7.4 versions any more)
Fixed in versions: 8.4.1, 8.3.8, 8.2.14, 8.1.18, 8.0.22, 7.4.26
Severity: C - A vulnerabilty that is exploitable for privilege escalation, but requiring a valid prior login.
CVE-2007-2138 was previously tracked via bug #237680 and bug #237682, more info on the updates addressing this flaw is available at: https://www.redhat.com/security/data/cve/CVE-2007-2138.html
Quoting upstream PostgreSQL security page: http://www.postgresql.org/support/security.html
If PostgreSQL is configured with LDAP authentication, and your LDAP configuration allows anonymous binds, it is possible for a user to authenticate themselves with an empty password.
Affected versions: 8.3, 8.2
Fixed in versions: 8.3.8, 8.2.14
Severity: A - A vulnerability that is exploitable for privilege escalation without requiring a prior login.
Buffer overflow in the gettoken function in contrib/intarray/intbool.c in the intarray array module in PostgreSQL 9.0.x before 9.0.3, 8.4.x before 8.4.7, 8.3.x before 8.3.14, and 8.2.x before 8.2.20 allows remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via integers with a large number of digits to unspecified functions.
cryptblowfish before 1.1, as used in PHP before 5.3.7 on certain platforms, PostgreSQL before 8.4.9, and other products, does not properly handle 8-bit characters, which makes it easier for context-dependent attackers to determine a cleartext password by leveraging knowledge of a password hash.
A denial of service flaw was found in the way pgbouncer, a lightweight connection pooler for PostgreSQL, performed processing of client requests attempting to add new database(s) with large name(s). A remote attacker could use this flaw to cause pooler server shutdown.
Relevant upstream patch: [1] http://git.postgresql.org/gitweb/?p=pgbouncer.git;a=commitdiff;h=4b92112b820830b30cd7bc91bef3dd8f35305525
References: [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692103
CREATE TRIGGER in PostgreSQL 8.3.x before 8.3.18, 8.4.x before 8.4.11, 9.0.x before 9.0.7, and 9.1.x before 9.1.3 does not properly check the execute permission for trigger functions marked SECURITY DEFINER, which allows remote authenticated users to execute otherwise restricted triggers on arbitrary data by installing the trigger on an attacker-owned table.
CRLF injection vulnerability in pgdump in PostgreSQL 8.3.x before 8.3.18, 8.4.x before 8.4.11, 9.0.x before 9.0.7, and 9.1.x before 9.1.3 allows user-assisted remote attackers to execute arbitrary SQL commands via a crafted file containing object names with newlines, which are inserted into an SQL script that is used when the database is restored.
SQL injection vulnerability in Quassel IRC before 0.9.1, when Qt 4.8.5 or later and PostgreSQL 8.2 or later are used, allows remote attackers to execute arbitrary SQL commands via a \ (backslash) in a message.
PostgreSQL, possibly 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, 8.4.x before 8.4.17, and 8.3.x before 8.3.23 incorrectly provides the superuser password to scripts related to "graphical installers for Linux and Mac OS X," which has unspecified impact and attack vectors.
PostgreSQL, 9.2.x before 9.2.4, 9.1.x before 9.1.9, 9.0.x before 9.0.13, 8.4.x before 8.4.17, and 8.3.x before 8.3.23 generates insecure temporary files with predictable filenames, which has unspecified impact and attack vectors related to "graphical installers for Linux and Mac OS X."
An array index error, leading to out of heap-based buffer bounds read flaw was found in the way PostgreSQL, an advanced Object-Relational database management system (DBMS), performed retrieval of textual form of error message representation when processing certain enumeration types. An unprivileged database user could issue a specially-crafted SQL query that, when processed by the server component of the PostgreSQL service, would lead to denial of service (daemon crash) or disclosure (of certain portions of) server memory.
The crypt function in contrib/pgcrypto in PostgreSQL before 9.0.23, 9.1.x before 9.1.19, 9.2.x before 9.2.14, 9.3.x before 9.3.10, and 9.4.x before 9.4.5 allows attackers to cause a denial of service (server crash) or read arbitrary server memory via a "too-short" salt.
The interactive installer in PostgreSQL before 9.3.15, 9.4.x before 9.4.10, and 9.5.x before 9.5.5 might allow remote attackers to execute arbitrary code by leveraging use of HTTP to download software.
The (1) brinpagetype and (2) brinmetapageinfo functions in the pageinspect extension in PostgreSQL before 9.5.x before 9.5.2 allows attackers to bypass intended access restrictions and consequently obtain sensitive server memory information or cause a denial of service (server crash) via a crafted bytea value in a BRIN index page.
PostgreSQL before 9.5.x before 9.5.2 does not properly maintain row-security status in cached plans, which might allow attackers to bypass intended access restrictions by leveraging a session that performs queries as more than one role.
PostgreSQL PL/Java after 9.0 does not honor access controls on large objects.
DISPUTED An issue was discovered in PostgreSQL 12.2 allows attackers to cause a denial of service via repeatedly sending SIGHUP signals. NOTE: this is disputed by the vendor because untrusted users cannot send SIGHUP signals; they can only be sent by a PostgreSQL superuser, a user with pgreloadconf access, or a user with sufficient privileges at the OS level (the postgres account or the root account).
Odyssey passes to client unencrypted bytes from man-in-the-middle When Odyssey storage is configured to use the PostgreSQL server using 'trust' authentication with a 'clientcert' requirement or to use 'cert' authentication, a man-in-the-middle attacker can inject false responses to the client's first few queries. Despite the use of SSL certificate verification and encryption, Odyssey will pass these results to client as if they originated from valid server. This is similar to CVE-2021-23222 for PostgreSQL.
aiven-extras is a PostgreSQL extension. Versions prior to 1.1.9 contain a privilege escalation vulnerability, allowing elevation to superuser inside PostgreSQL databases that use the aiven-extras package. The vulnerability leverages missing schema qualifiers on privileged functions called by the aiven-extras extension. A low privileged user can create objects that collide with existing function names, which will then be executed instead. Exploiting this vulnerability could allow a low privileged user to acquire superuser privileges, which would allow full, unrestricted access to all data and database functions. And could lead to arbitrary code execution or data access on the underlying host as the postgres user. The issue has been patched as of version 1.1.9.
It was found that the buffers used to hold datetime output were too small. Long output could lead to a stack-based buffer overflow, possibly allowing an authenticated database user to crash the PostgreSQL server or execute arbitrary code.
Acknowledgements:
Red Hat would like to thank the PostgreSQL project for reporting this issue. Upstream acknowledges Noah Misch as the original reporter.
Multiple integer overflow flaws, leading to buffer overflows, were found in PostgreSQL. An authenticated database user could possibly use these flaws to crash the PostgreSQL server or execute arbitrary code.
Acknowledgements:
Red Hat would like to thank the PostgreSQL project for reporting this issue. Upstream acknowledges Heikki Linnakangas and Noah Misch as the original reporters.
A flaw was found in the way the PostgreSQL enforced permission checks on scripts written in PL/Perl. Once the PL/Perl procedural language was registered on particular database, a remote, authenticated user, privileged to create databases, running a specially-crafted PL/Perl script, could use this flaw to bypass intended PL/Perl trusted mode restrictions, allowing them to run arbitrary Perl scripts with the privileges of the database server.
References: [1] PostgreSQL PL/Perl procedural language manual page: http://www.postgresql.org/docs/8.1/interactive/plperl.html [2] PostgreSQL Trusted and Untrusted PL/Perl mode manual page: http://www.postgresql.org/docs/8.1/interactive/plperl-trusted.html
Acknowledgements:
Red Hat would like to thank Tim Bunce for responsibly reporting this issue.
Quoting upstream PostgreSQL security page: http://www.postgresql.org/support/security.html
If PostgreSQL is configured with LDAP authentication, and your LDAP configuration allows anonymous binds, it is possible for a user to authenticate themselves with an empty password.
Affected versions: 8.3, 8.2
Fixed in versions: 8.3.8, 8.2.14
Severity: A - A vulnerability that is exploitable for privilege escalation without requiring a prior login.
Quoting upstream PostgreSQL security page: http://www.postgresql.org/support/security.html
Authenticated non-superusers can shut down the backend server by re-LOAD-ing libraries in $libdir/plugins, if any libraries are present there.
Affected versions: 8.4, 8.3, 8.2
Fixed in versions: 8.4.1, 8.3.8, 8.2.14
Severity: D - A vulnerability that is exploitable for denial-of-service, but requiring a valid prior login.