COMMAND
netscape, IE
SYSTEMS AFFECTED
Systems using NS, MSIE
PROBLEM
This probably isn't ripe for release yet, given that Netscape
hasn't fixed it yet, but unfortunately the whole world knows
about it now that it's been on SlashDot. Basically, an unsigned
Java applet in Netscape can read any file on the system AND act
as a web server, serving those files to anywhere in the world.
This is due to a bug in Java and a bug in Netscape.
More info at:
http://www.brumleve.com/BrownOrifice/
On August 5th, code was made public by Dan Brumleve, which
demonstrates a serious security hole in the Netscape Java
distribution. This vulnerability allows a hostile web site to
start a server process on the browser system. That server can
access arbitrary files on the browser system and locally
connected networks through "file:" URLs. All versions of Netscape
Navigator and Netscape Communicator versions 4.74 and earlier are
vulnerable when Java is enabled. Mozilla from mozilla.org is not
currently vulnerable. Preview 1 of Mozilla from Netscape
(Netscape 6 Preview 1) is expired and cannot be tested.
A hostile web server can start a server process on the browser
system with no warning to the browsing user. This process can
access any file on the local (browser) machine or the locally
connected network through normal file sharing, if it is accessible
by the browsing user. Additional code and external URLs can also
be distributed by the running server, resulting in
self-propagation and feedback to the hostile site.
Netscape Communicator 4.74 and earlier with Java and downloadable
plugins enabled are affected. Netscape Navigator 4.74 and earlier
with Java and downloadable plugins enabled. Affected platforms
are all platforms on which Java and Netscape are available are
vulnerable. This is a platform independent exploit. Systems
running Windows 2000, Windows NT and Linux are known to be
vulnerable through demonstration.
Upon execution from a hostile web page, a hostile Java applet
downloads a set of socket classes permitting it to create a web
server within the Browser Java runtime environment. Through the
use of the socket class, the exploit code listens on a
configurable port number (the default port is 8080, the httpd
proxy port). Through the use of "file:" URLs, this hostile server
code is capable of accessing any local files, including any
network files that can be reached, through file sharing, from the
local file system.
The origination site contains clear warnings that this code is a
security vulnerability, but nothing in the nature of this exploit
requires a warning to the user from the browser. Like any other
Java applet, this can run with no execution warning.
The origination page also does not fully describe the sample
exploit server's behavior. In addition to starting up a web
server, the pages delivered by the web server contain image
references back to the originating host. Any browsers that
connect to a compromised system reveal themselves to the
origination site. This introduces the possibility for further
propagation of similar exploits, through redirection or references
to the hostile code from the hostile server itself.
Self-propagating versions of this exploit have not been observed
at this time.
The origination site contains a "BOHTTPD_spy" page containing a
list of sites known to have executed the code. This list is being
actively exploited by other sites around the world, which are
attempting to browse or break into the compromised sites. Some of
these attempts appear to be automated, while many appear to be
simple manual browsing. These sites may be unaware that their own
efforts to browse the compromised sites are being revealed to the
origination site, along with the IP address and port that they are
browsing.
Code available from http://www.brumleve.com/BrownOrifice includes
Java source code for the sample exploit that could be readily
modified for more malicious use.
Brumleve's demonstration page politely asks users to specify a
directory on their computer for public access. However, by
specifying "\.." in HTTP requests to the server, an attacker can
navigate the server's file system and view/download any files.
For example,
http://your-ip-address:8080/C:/temp/\../
or
http://your-ip-address:8080/C:/temp/%5C../
(for Internet Explorer as a client) will display the contents of
the root directory of C: drive of the server's computer.
A simpler traversal option is to click on the "Up to higher level
directory" link when browsing the affected machine. This has
worked on all of the windows machines that visited with BOHTTPD
Spy (Brian Wilson's information). He gotten 'Permission Denied.'
messages on some machines that appeared to be *ix platforms when
trying to traverse higher than the 'share point'.
We should be worried about a combination of a rogue applet and a
rogue servlet (for example CGI-script), both on the same server
on the internet. The applet, downloaded and started on a victims
browser inside Intranet, assuming his firewall allows him to
receive Java applets, would build up a connection to the rogue
servlet implementing a kind of "reverse tunnel" similar to SSH.
This tunnel would principially receive a line from the rogue
servlet, interpreting this as URL by sending it through
netscape.net.URLConnection/URLInputStream. The result would be
sent back to the rogue servlet, then repeating these actions in
an endless loop or until the victim exits his browser. This way
the servlet can use the tunnel to its applet in order to read any
file on teh victims machine without the firewall being able to
prevent it.
But it becomes worse... When tried these buggy Java methods and
found that they do not only work for accessing local files on the
victims PC. Much worse, they allow access to ANY URL (!) the
victims browser can reach! In above scenario, the rogue servlet
would not only be able to read all files on the victims machine,
but freely surf inside the Intranet where the vicitm is located.
Regardless whether it is VPN-protected or whatever, the servlet
would see what the victims browser can see. It is easy to verify
that: Access above site, activate the rogue applet-server,
conenct to it, but give an URL instead of a filename (the Java
applet actually takes care of it, it doesn't prepend "file://" if
you start the location with "http://", "ftp://", etc - see its
sourcefile BOHTTPD.java). Sor, try for example to access
"http://your.victim.browser:8080/http://www.your.intranet.server"
and you will see taht this way you can see what your victim
browser sees. It is not very useful per se, as you can usually
see these machines anyway (otherwise you could not connect to the
victim browser). But if the rogue applet initiated a tunnel as
described above - and most firewalls would allow this because it
is outgoing - it DOEs become a problem. In short, it would
deactivate your firewall, the combination of rogue applet on your
Intranet victim machine plus rogue servlet on the Internet
machine can work as (reverse) proxy into your Intranet! Actually
teh rogue servlet could itself be combined with a WWW frontend
allowing access to teh Intranet.
It even becomes worse than that - as if it were not bad enough.
Andreas Greulich is using personal X.509 certificates in order to
authenticate SSL connections. We are not speaking about standard
server-authentication now; we are speaking about client
authentication, ie the scneario where your oersinal browser has a
personal certificate installed and uses this for authentication.
These certificates are still quite rare (estimated 2% of all SSL
traffic), but becoming important, for example for Internet
banking. Private keys for personal certificates are usually
stored on your local disk, protected (ie encrypted) by a
passphrase. Netscape can be congigured in a way this passphrase
has only to be given once per Netscape session - it is then
cached for subsequent authentications, and Netscape performs
these automagically. Most peopel have this otpion activated. If
they are very security-concerned, they will use the option that
asks again for the passphrase after 30 minutes of not being used.
Hardly anybody has it set up in a way it is asked every time. It
would be impractical to work with it that way.
Now the problem is that, once your personal certificate is
"opened" in above way (so teh user entered it once and teh
browser cached it), Netscape will automagically use it again
without informing the user - even if this request is performed
using netscape.net.URLConnetion/URLInputStream! This means, the
rogue servlet does nto only see what the victims browser sees, but
can also authenticate itself in the same way teh victims browser
could do on its behalf without direct user interaction.
To try it out, make sure you have a browser with personal
certificate installed, passphrase, and set it up so that it asks
only once a session for it. Then use it to connect to a server
that needs you to unlock the certificate (ie enter passphrase),
say "https://your.bank.com". Netscape now keeps that in cache.
Now get teh rogue applet mentioned above. Then go to another
browser (like starting the Explorer on your machine), and connect
to "http://your.victim.browser:8080/https://your.bank.com". And
bingo, here you are, and authenticated.
Verify yourself by trying the following refined proof of concept
Applet:
http://java-house.etl.go.jp/~takagi/java/test/Brumleve-BrownOrifice-modified-netscape.net.URLConnection/Test.html
Mac OS version is also affected.
And another one for the other vulnerability(*1) disclosed by Brown
Orifice is here:
http://java-house.etl.go.jp/~takagi/java/test/Brumleve-BrownOrifice-modified-java.net.ServerSocket/Test.html
This does not work behind firewalls or with Proxy servers. How it
works:
1. The applet opens ServerSocket with a randomly selected port
2. The applet calls accept() method to wait for an incoming
connection
3. The applet invokes a CGI on the codebase host
4. The CGI gets the IP address of the browser host
5. The CGI requests a third party host, which is a Proxy
server of our site, to make a connection to the browser's
port
6. The third party host makes a connection to the browser's
port
7. The applet accepts the connection and obtains a Socket
object
8. The applet obtains an InputStream object from the Socket
object
The source code is here:
http://java-house.etl.go.jp/~takagi/java/test/Brumleve-BrownOrifice-modified-java.net.ServerSocket/Test.java
The same security hole, exists in MSIE too, with one restriction:
url can't start with file:. But still the applet from outside
site, can access you intranet servers including ftps and ALL
sites you have access to. The demonstration of the bug is here:
http://www.oltres.com/ms-bug/
The applet was tested on WinNT 4.0sp5 with Internet Explorer both
5 and 5.5 versions.
"file:" url can be used to exploit. Malicious applet certainly
cannot read content of files, but it can determine whether the
specified file exists or not.
try {
new WURLConnection("file:/C:/WINDOWS/Cookies/default@playboy[1].txt");
} catch (SecurityException e) {
System.out.println("You have visited the Playboy site.");
} catch (java.io.FileNotFoundException e) {
System.out.println("You may not have visited the Playboy site.");
}
Takagi has confirmed that "about:global" url also can be used to
exploit. This makes the problem more serious.
SOLUTION
No fix is available from Netscape as of this writing. Until a
fix becomes available, Java should be disabled in the browser.
Disabling the "downloader plugin" can also prohibit the
downloading of the required socket classes that this exploit
requires for operation.
Mozilla does not natively support Java, there are hooks for it to
support your favorite JVM. So some people that use Mozilla may
be vulnerable but they will know who they are. If you try to
view/run Java with standard Mozilla the browser will crash, but
what do you expect its ALPHA code.
Linux-Mandrake recommends you disable Java to make Netscape
invulnerable to this exploit. You can disable Java by hand in
Edit -> Preferences -> Advanced. You can also remove the
preferences.js file by using:
rm -f ~/.netscape/preferences.js
Patches for Mandrake:
Linux-Mandrake 6.0: 6.0/RPMS/netscape-common-4.75-2mdk.i586.rpm
6.0/RPMS/netscape-communicator-4.75-2mdk.i586.rpm
6.0/RPMS/netscape-navigator-4.75-2mdk.i586.rpm
6.0/SRPMS/netscape-4.75-2mdk.src.rpm
Linux-Mandrake 6.1: 6.1/RPMS/netscape-common-4.75-2mdk.i586.rpm
6.1/RPMS/netscape-communicator-4.75-2mdk.i586.rpm
6.1/RPMS/netscape-navigator-4.75-2mdk.i586.rpm
6.1/SRPMS/netscape-4.75-2mdk.src.rpm
Linux-Mandrake 7.0: 7.0/RPMS/netscape-castellano-4.75-1mdk.noarch.rpm
7.0/RPMS/netscape-common-4.75-2mdk.i586.rpm
7.0/RPMS/netscape-communicator-4.75-2mdk.i586.rpm
7.0/RPMS/netscape-francais-4.75-1mdk.noarch.rpm
7.0/RPMS/netscape-navigator-4.75-2mdk.i586.rpm
7.0/RPMS/netscape-walon-4.75-1mdk.noarch.rpm
7.0/SRPMS/netscape-4.75-2mdk.src.rpm
7.0/SRPMS/netscape-castellano-4.75-1mdk.src.rpm
7.0/SRPMS/netscape-francais-4.75-1mdk.src.rpm
7.0/SRPMS/netscape-walon-4.75-1mdk.src.rpm
Linux-Mandrake 7.1: 7.1/RPMS/netscape-castellano-4.75-1mdk.noarch.rpm
7.1/RPMS/netscape-catalan-4.75-1mdk.noarch.rpm
7.1/RPMS/netscape-common-4.75-3mdk.i586.rpm
7.1/RPMS/netscape-communicator-4.75-3mdk.i586.rpm
7.1/RPMS/netscape-euskara-4.75-1mdk.noarch.rpm
7.1/RPMS/netscape-francais-4.75-1mdk.noarch.rpm
7.1/RPMS/netscape-navigator-4.75-3mdk.i586.rpm
7.1/RPMS/netscape-russian-4.75-1mdk.noarch.rpm
7.1/RPMS/netscape-walon-4.75-1mdk.noarch.rpm
7.1/SRPMS/netscape-4.75-3mdk.src.rpm
7.1/SRPMS/netscape-castellano-4.75-1mdk.src.rpm
7.1/SRPMS/netscape-catalan-4.75-1mdk.src.rpm
7.1/SRPMS/netscape-euskara-4.75-1mdk.src.rpm
7.1/SRPMS/netscape-francais-4.75-1mdk.src.rpm
7.1/SRPMS/netscape-russian-4.75-1mdk.src.rpm
7.1/SRPMS/netscape-walon-4.75-1mdk.src.rpm
Alexey Yarovinsky tried to write a patch to the Netscape Java bug.
Seems to be useful:
http://www.oltres.com/ns-bug/
Conectiva Linux:
ftp://atualizacoes.conectiva.com.br/4.0/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.0/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.0/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.0/i386/netscape-navigator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.0es/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.0es/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.0es/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.0es/i386/netscape-navigator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.1/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.1/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.1/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.1/i386/netscape-navigator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.2/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.2/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.2/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.2/i386/netscape-navigator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.0/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/5.0/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.0/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.0/i386/netscape-navigator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.1/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/5.1/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.1/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.1/i386/netscape-navigator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/netscape-navigator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/SRPMS/netscape-4.75-1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/netscape-common-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/netscape-communicator-4.75-1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/netscape-navigator-4.75-1cl.i386.rpm
For Red Hat:
alpha: ftp://updates.redhat.com/6.2/alpha/netscape-common-4.75-0.6.2.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/netscape-communicator-4.75-0.6.2.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/netscape-navigator-4.75-0.6.2.alpha.rpm
i386: ftp://updates.redhat.com/6.2/i386/netscape-common-4.75-0.6.2.i386.rpm
ftp://updates.redhat.com/6.2/i386/netscape-communicator-4.75-0.6.2.i386.rpm
ftp://updates.redhat.com/6.2/i386/netscape-navigator-4.75-0.6.2.i386.rpm
sources: ftp://updates.redhat.com/6.2/SRPMS/netscape-4.75-0.6.2.src.rpm
ftp://updates.redhat.com/6.2/SRPMS/netscape-alpha-4.75-0.6.2.src.rpm
For Caldera Systems:
- OpenLinux Desktop 2.3: ftp://ftp.calderasystems.com/pub/updates/OpenLinux/2.3/current/RPMS/communicator-4.75-1OL.i386.rpm
ftp://ftp.calderasystems.com/pub/updates/OpenLinux/2.3/current/SRPMS/communicator-4.75-1OL.src.rpm
- OpenLinux eServer 2.3 and OpenLinux eBuilder for ECential 3.0
ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/communicator-4.75-1S.i386.rpm
ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/SRPMS/communicator-4.75-1S.src.rpm
- OpenLinux eDesktop 2.4 ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/RPMS/communicator-4.75-1.i386.rpm
ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/SRPMS/communicator-4.75-1.src.rpm
SuSE says that the temporary workaround for this problem is to
disable Java in Netscape's configuration menu (to protect against
other vulnerabilities, disable JavaScript, too!). Patches:
ftp://ftp.suse.com/pub/suse/i386/update/6.4/xap1/netscape.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.4/xap1/netscape.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.4/xap1/netscape.rpm
SuSE-6.1, SuSE-6.0: We do _NOT_ provide Netscape packages of
version 4.75 because there is no such version from netscape that
is linked against glibc2.0. We recommend to install the libc5
version from SuSE-5.3 (which requires the package shlibs5
installed). Netscape-4.74 (which fixes the security related bug
in Netscape's jpeg library) is available though. Since this
version does not provide a complete fix for Netscape's known
security problems, SuSE don't list any links to this version.
Interested parties may find the packages at the corresponding
places:
ftp://ftp.suse.com/pub/suse/i386/update/5.3/xap1/netscape.rpm
Available for download:
http://www.netscape.com/computing/download/index.html
it seems patching the brown orifice issue.
Miscrosoft, I believe, addressed this with new java engine.
Versions of the Microsoft VM are identified by build numbers,
which can be determined using the JVIEW tool, as discussed in the
FAQ. The following builds of the Microsoft VM are affected:
- All builds in the 2000 series.
- All builds in the 3100 series.
- All builds in the 3200 series.
- All builds in the 3300 series.
Patch availability:
- All 2000 series Microsoft VM customers: Install Microsoft VM
build 2446
- http://www.microsoft.com/java/vm/dl_vmsp2.htm
- All 3100 series Microsoft VM customers: Upgrade to build 3309
- http://www.microsoft.com/java/vm/dl_vm40.htm
and install the 3314 security patch
- http://download.microsoft.com/download/vm/Patch/3314/WIN98Me/EN-US/vmsecfix.exe
- 3200 series Microsoft VM customers should do one of the
following:
- All 3200 builds: Upgrade to build 3309 and install the
3314 security patch
- Builds 3229-3234: Install the security patch from Bulletin
MS00-011 before installing this new 3314 security patch
- Build 3240: Install the 3314 security patch
- All 3300 series Microsoft VM customers should install the
3314 security patch
How to determine the build number for your version of the MS VM?
Open a command window: On Windows NT or Windows 2000, choose
"Start", then "Run", then type "CMD" and hit the enter key. On
Windows 95 or 98, choose "Start", then "Run" then type "COMMAND"
and hit the enter key. At the command prompt, type "JVIEW" and
hit the enter key. The version information will be at the right
of the topmost line. It will have a format like "5.00.xxxx",
where the "xxxx" is the build number. For example, if the version
number is 5.00.1234, you have build number 1234.
For FreeBSD this can be worked around by disabling Java in the
"Advanced" section of the Preferences control panel. Solution is
one of the following:
1) Upgrade your entire ports collection and rebuild the relevant
netscape port.
2) Deinstall the old package and install a new package dated
after the correction date, obtained from the following
directories:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/
3) download a new port skeleton for the netscape port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
For Turbo Linux:
ftp://ftp.turbolinux.com/pub/updates/6.0/security/netscape-communicator-4.75-1.i386.rpm
ftp://ftp.turbolinux.com/pub/updates/6.0/SRPMS/netscape-communicator-4.75-1.src.rpm
For Debian:
http://security.debian.org/dists/potato/updates/non-free/source/netscape4.75_4.75-1potato1.diff.gz
http://security.debian.org/dists/potato/updates/non-free/source/netscape4.75_4.75-1potato1.dsc
http://security.debian.org/dists/potato/updates/non-free/source/netscape4.75_4.75.orig.tar.gz
http://security.debian.org/dists/potato/updates/non-free/source/netscape4.base_4.75-1.dsc
http://security.debian.org/dists/potato/updates/non-free/source/netscape4.base_4.75-1.tar.gz
http://security.debian.org/dists/potato/updates/non-free/binary-i386/communicator-base-475_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/communicator-nethelp-475_4.75-1potato1_all.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/communicator-smotif-475-libc5_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/communicator-smotif-475_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/communicator-spellchk-475_4.75-1potato1_all.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/communicator_4.75-1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/navigator-base-475_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/navigator-nethelp-475_4.75-1potato1_all.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/navigator-smotif-475-libc5_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/navigator-smotif-475_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/navigator_4.75-1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-base-4-libc5_4.75-1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-base-475_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-base-4_4.75-1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-ja-resource-475_4.75-1potato1_all.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-java-475_4.75-1potato1_all.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-ko-resource-475_4.75-1potato1_all.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-smotif-475-libc5_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-smotif-475_4.75-1potato1_i386.deb
http://security.debian.org/dists/potato/updates/non-free/binary-i386/netscape-zh-resource-475_4.75-1potato1_all.deb