← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:35191 · Disclosed 2008-12-16

RHEL 4 / 5 : firefox

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a booby-trapped brochure, not an unlocked front door

RHSA-2008:1036 is a Firefox client-side rollup for RHEL 4 and 5, not a remotely reachable daemon flaw. The advisory bundles multiple issues fixed in Firefox 3.0.5, including memory-corruption bugs that *could* lead to code execution, same-origin bypasses, XSS/session-restore issues, URL parsing quirks, and CSS parser weirdness. For Red Hat packaging, the relevant fixed builds are RHEL 4: firefox-3.0.5-1.el4, nspr-4.7.3-1.el4, nss-3.12.2.0-1.el4 and RHEL 5: firefox-3.0.5-1.el5_2, nspr-4.7.3-2.el5, nss-3.12.2.0-2.el5, xulrunner-1.9.0.5-1.el5_2.

Vendor CRITICAL is technically understandable because some bundled Mozilla advisories were rated critical and included potential arbitrary code execution during normal browsing. But in a 10,000-host enterprise patch queue, that score overstates today's operational risk: exploitation requires user interaction, an actually installed and used desktop browser on RHEL 4/5, and there is no KEV listing or current exploitation signal. This is real risk on the small number of legacy endpoints that still browse the web, but it is not the same class as an unauthenticated internet-facing RCE.

"Old browser debt on legacy RHEL, yes; enterprise-wide critical patch fire drill, no."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on hostile content

The attacker needs a phishing email, IM link, compromised intranet page, or malicious ad to drive the victim into Firefox. This is classic browser-exploit delivery, not direct network reachability. The 'weaponized tool' here is the malicious HTML/JavaScript page itself, built to trigger one of the Firefox 3.0.5-fixed bugs documented by Mozilla.
Conditions required:
  • A human user must browse to attacker-controlled content
  • The target host must have Firefox installed and used interactively
  • Outbound web access must be available
Where this breaks in practice:
  • No user, no exploit
  • Server-class RHEL deployments often have Firefox installed but never launched
  • Email security, web filtering, and browser isolation can kill the lure before execution
Detection/coverage: Email gateways, secure web gateways, and proxy logs are the best visibility here. Nessus detects package state locally; it does not prove active browser usage.
STEP 02

Trigger a browser-engine flaw

Once the page renders, the exploit must reliably hit one of the bundled issues: memory corruption in layout/JS paths (Mozilla MFSA 2008-60), XBL/XPCNativeWrapper privilege issues (MFSA 2008-68), SessionStore abuse (MFSA 2008-69), or cross-origin leakage tricks. The most dangerous path is code execution or chrome-privileged JavaScript during normal browsing.
Conditions required:
  • Firefox version must be older than the RHSA fixed build
  • Exploit content must match the vulnerable engine path
  • The user must render the content without the browser crashing before useful impact
Where this breaks in practice:
  • Old browser exploitation is brittle and version-specific
  • Mozilla described some RCE paths as presumed-exploitable memory corruption, not turnkey one-click public weaponization
  • Tenable still records 'No known exploits are available' for the advisory
Detection/coverage: Signature coverage is inconsistent; network IDS may see exploit-kit-style delivery but often misses browser-engine specifics. Host telemetry is stronger than perimeter signatures.
STEP 03

Gain same-origin bypass or user-context code execution

Successful exploitation yields either data theft across origins or arbitrary JavaScript/code execution in the browser's privileged context. On Linux, that generally means impact at the logged-in user's level, not immediate root. The 'weaponized tool' becomes the browser process itself, with follow-on payload staging through the user's session.
Conditions required:
  • The target user must have valuable session data or enough local privilege to matter
  • The attack must escape from mere crash/DoS into reliable control or theft
Where this breaks in practice:
  • Blast radius is usually one user session
  • No direct privilege escalation to root is described in the RHSA
  • Legacy desktops that still exist are often segmented, kiosked, or low-trust by design
Detection/coverage: Look for unusual child processes from firefox, outbound beacons, dropped files in the user's home, and anomalous proxy activity tied to the interactive account.
STEP 04

Operationalize the foothold

The attacker still needs a second stage to turn browser compromise into meaningful enterprise impact. On a modern enterprise network, post-browser actions are where EDR, proxy controls, network segmentation, and credential protections should start to bite. That extra post-exploitation work is why this does not deserve server-side emergency treatment.
Conditions required:
  • A payload must execute or stolen browser data must be monetizable
  • The compromised host must reach further internal assets
Where this breaks in practice:
  • EDR and egress controls commonly catch the post-exploitation phase
  • Legacy RHEL endpoints are usually a small, exceptional population rather than broad enterprise standard
  • Internal movement still requires separate credentials and reachability
Detection/coverage: EDR should have the best shot here. If you only have package scanners, you will know the host is old, not whether the browser is being weaponized.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current public evidence of active exploitation found. Tenable's plugin still says 'No known exploits are available'.
KEV statusNot KEV-listed based on review against CISA's Known Exploited Vulnerabilities Catalog.
Proof-of-concept availabilityI did not find a widely used current public exploit repo for this RHSA rollup. Mozilla and Red Hat primarily reference advisories and bug trackers, not a weaponized PoC ecosystem.
EPSSRepresentative included issue CVE-2008-5507 shows EPSS 0.53% / 64.9th percentile in Feedly's CVE view, sourced from FIRST EPSS. That's not zero, but it is far from 'drop everything'.
Vendor baselineRed Hat marked the advisory Critical and Tenable maps the rollup to CVSS v2 10.0 via AV:N/AC:L/Au:N/C:C/I:C/A:C.
CVSS reality checkThat vector models the worst RCE path in a vacuum. It misses the practical prerequisites: user interaction, client-side exposure only, and narrow legacy endpoint population.
Affected versionsRHEL 4 and 5 systems with Firefox older than the RHSA builds are affected. Upstream Mozilla fixed these issues in Firefox 3.0.5 on 2008-12-16.
Fixed versionsRHEL 4: firefox-3.0.5-1.el4, nspr-4.7.3-1.el4, nss-3.12.2.0-1.el4. RHEL 5: firefox-3.0.5-1.el5_2, nspr-4.7.3-2.el5, nss-3.12.2.0-2.el5, xulrunner-1.9.0.5-1.el5_2.
Exposure/scanning realityInternet-exposure engines like Shodan/Censys are the wrong lens here because Firefox is not a listening service. This is a local package inventory problem on interactive Linux endpoints.
Disclosure and researchersRed Hat issued RHSA-2008:1036 on 2008-12-16. Mozilla credits Mozilla developers, moz_bug_r_a4, Chip Salzenberg, and IBM researchers Justin Schuh, Tom Cross, and Peter William across the bundled advisories.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The decisive downgrading factor is attacker position: this is a client-side browser issue that requires a user to load hostile content, not an unauthenticated service reachable across your estate. The second big dampener is exposure population: the number of enterprises that still have actively browsed Firefox on RHEL 4/5 should be tiny, even if the installed package still shows up in scans.

HIGH Prerequisite and exposure-chain analysis
MEDIUM Current exploit-prevalence assessment

Why this verdict

  • Start from vendor 10.0, then cut hard for client-side reachability: the attacker does not hit a remotely exposed daemon; they need a person to browse to hostile content.
  • Cut again for implied prior stage: phishing, malvertising, or web-lure delivery is a separate initial-access step, which means this is downstream of controls like email security, proxy filtering, and browser isolation.
  • Cut again for reachable population: only legacy RHEL 4/5 systems with Firefox actually installed and used interactively matter; that is a much smaller slice than the advisory product matrix suggests.
  • Cut again for blast radius: successful exploitation lands in the logged-in user's context, not automatic root on a server fleet.
  • Keep it at MEDIUM, not LOW: the advisory does include plausible RCE/chrome-privilege paths during normal browsing, so any legacy kiosk, admin workstation, or jump-host with active browser use is still bad debt.

Why not higher?

I am not scoring this HIGH or CRITICAL because the attack chain is stacked with real-world friction: user interaction, client-side execution, legacy platform dependency, and a likely tiny exposed population. There is also no KEV entry or modern exploitation drumbeat to justify emergency treatment across an enterprise fleet.

Why not lower?

I am not dropping this to LOW because some of the included Mozilla issues were explicitly treated as critical by Mozilla and Red Hat due to potential arbitrary code execution or privileged JavaScript during normal browsing. On any still-used legacy endpoint, compromise can still hand an attacker a real foothold.

05 · Compensating Control

What to do — in priority order.

  1. Block legacy browsing paths — If these RHEL 4/5 hosts still exist, stop them from browsing arbitrary internet content by proxy policy, outbound ACLs, or browser isolation. For a MEDIUM verdict there is no mitigation SLA; use this control where patching or retirement cannot happen immediately, then complete remediation within 365 days.
  2. Inventory actual browser use — Separate 'package installed' from 'browser actually used' by pulling process execution, proxy, and login telemetry. There is no mitigation SLA — go straight to the 365-day remediation window, but do the inventory now so you do not spend cycles patching dead packages on non-interactive servers.
  3. Retire or isolate legacy endpoints — A host still vulnerable to a 2008 Firefox rollup is almost certainly carrying broader unsupported-software risk. Put those systems into a legacy enclave, strip outbound web access where feasible, and finish remediation or decommissioning within 365 days.
  4. Hunt for browser-spawned payloads — Use EDR or shell history review to look for unusual child processes from firefox, suspicious downloads under user homes, or strange outbound sessions. There is no mitigation SLA for MEDIUM, but this is the fastest way to tell whether the residual risk is theoretical or operational.
What doesn't work
  • A WAF does not help; the vulnerable component is the user's browser, not your web app edge.
  • Internet exposure scanning via Shodan/Censys does not help; Firefox is not a listening service and this advisory is a local-package check.
  • Treating this like a server RCE and mass-patching every RHEL node with the package present wastes time; the real question is which hosts still browse.
06 · Verification

Crowdsourced verification payload.

Run this on the target RHEL host itself as root or with an account that can query the local RPM database. Save it as check_rhsa_2008_1036.sh, then run bash check_rhsa_2008_1036.sh; it checks installed RPM capabilities against the RHSA fixed versions and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/bash
# check_rhsa_2008_1036.sh
# Determine exposure to RHSA-2008:1036 on RHEL 4/5 using RPM package capability/version checks.
# Exit codes: 0=PATCHED/not-applicable, 1=VULNERABLE, 2=UNKNOWN

set -u

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

if ! have_cmd rpm; then
  echo "UNKNOWN rpm-not-found"
  exit 2
fi

if ! rpm -q firefox >/dev/null 2>&1; then
  echo "PATCHED firefox-not-installed"
  exit 0
fi

RHEL_MAJOR="$(rpm --eval '%{?rhel}' 2>/dev/null)"
if [[ -z "$RHEL_MAJOR" || "$RHEL_MAJOR" == "%{?rhel}" ]]; then
  if [[ -r /etc/redhat-release ]]; then
    if grep -q 'release 4' /etc/redhat-release; then
      RHEL_MAJOR=4
    elif grep -q 'release 5' /etc/redhat-release; then
      RHEL_MAJOR=5
    else
      echo "UNKNOWN unable-to-determine-rhel-major"
      exit 2
    fi
  else
    echo "UNKNOWN unable-to-determine-rhel-major"
    exit 2
  fi
fi

check_req() {
  local req="$1"
  rpm -q --whatprovides "$req" >/dev/null 2>&1
}

missing=()

case "$RHEL_MAJOR" in
  4)
    check_req 'firefox >= 3.0.5-1.el4' || missing+=("firefox>=3.0.5-1.el4")
    check_req 'nspr >= 4.7.3-1.el4' || missing+=("nspr>=4.7.3-1.el4")
    check_req 'nss >= 3.12.2.0-1.el4' || missing+=("nss>=3.12.2.0-1.el4")
    ;;
  5)
    check_req 'firefox >= 3.0.5-1.el5_2' || missing+=("firefox>=3.0.5-1.el5_2")
    check_req 'nspr >= 4.7.3-2.el5' || missing+=("nspr>=4.7.3-2.el5")
    check_req 'nss >= 3.12.2.0-2.el5' || missing+=("nss>=3.12.2.0-2.el5")
    if rpm -q xulrunner >/dev/null 2>&1; then
      check_req 'xulrunner >= 1.9.0.5-1.el5_2' || missing+=("xulrunner>=1.9.0.5-1.el5_2")
    fi
    ;;
  *)
    echo "UNKNOWN unsupported-rhel-major-$RHEL_MAJOR"
    exit 2
    ;;
esac

if [[ ${#missing[@]} -eq 0 ]]; then
  echo "PATCHED all-required-rpms-meet-rhsa-2008-1036-level"
  exit 0
fi

echo "VULNERABLE missing:${missing[*]}"
exit 1
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat tenable:35191 like an internet-facing emergency across 10,000 hosts. First, identify the small subset of RHEL 4/5 systems where Firefox is actually launched by humans; for those, restrict browsing or isolate the host if it cannot be retired. For this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤ 365 days to get the RHSA-fixed packages on any still-legitimate legacy endpoint or, better, remove the browser / decommission the host entirely.

Sources

  1. Red Hat RHSA-2008:1036 advisory
  2. Tenable Nessus Plugin 35191
  3. Mozilla MFSA 2008-60
  4. Mozilla MFSA 2008-68
  5. Mozilla MFSA 2008-69
  6. Mozilla MFSA 2008-66
  7. NVD CVE-2008-5507
  8. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.