lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 28 May 2008 13:30:08 -0700
From: Marvin Simkin <Marvin.Simkin@....edu>
To: <bugtraq@...urityfocus.com>
Subject: Calcium web calendar: Reflected XSS

Vendor: Brown Bear Software
Vendor web page: http://brownbearsw.com/
Product: Calcium web calendar
Product web page: http://brownbearsw.com/calcium/WhatIsIt.html

Vendor's Product Description:
Calcium is a Web Calendar application. It will run on nearly any machine with a web server that can run Perl CGI scripts; a web browser is all you need to view, edit, and manage any number of calendars from any network connected computer. All administration is done with your browser - after installation, there's no need to log in to the web server.

Vulnerability class: Cross-Site Scripting
Severity: Medium

Vulnerability details:
Calcium web calendar is vulnerable to "reflected" (type 1) cross-site scripting (XSS).  For a discussion of the various types of XSS, and XSS in general, see
http://en.wikipedia.org/wiki/Cross_Site_Scripting

Proof of concept, version 4.0.4:
https://[yourserver]/cgi-bin/Calcium40.pl?Op=ShowIt&CalendarName=XSS_%3Cbody%20onload=alert(document.cookie)%3E_here

Impact:
Attacker could impersonate victim to do any activity the victim is authorized to do through a compromised web site, for example, initiate funds transfers or access private data. Under some circumstances the existence of this vulnerability in one web site could be used to attack other web sites in the same DNS domain. For example, if host "a.example.com" shares cookies with host "b.example.com" and "b" is vulnerable, "b" can be used to attack "a".

Versions tested:
Calcium 4.0.4  Vulnerable
Calcium 3.10   Vulnerable

Potential victims:
1. User web client with scripting languages enabled.
2. Web server hosting unpatched software.
3. Other web servers on the same DNS domain.

Workarounds:
1. Victim web client may disable scripting languages.
2. Vulnerable web site may temporarily shut down until patch can be applied.
3. Exposed web sites sharing the same DNS domain should not share authentication cookies with vulnerable site.

Researcher's quick patch for version 4.0.4:
Until vendor patch is received, this may help. Use at your own risk.
In file cgi-bin/CalciumDir40/Calendar/Database.pm
72c72
<     die "Bad Calendar or Database name! '$dbName' \n"
---
>     die "Bad Calendar or Database name!\n"

Vendor response:
Vendor provided a patch by email.

Local access to victim computer required: NO.

Victim user assistance required:
YES. For example, victim can be enticed to visit a malicious web page or open a malicious email.

Authentication required:
NO. Attack can be carried out by an unauthenticated attacker against an unauthenticated victim. However, if the victim has authenticated to a web site, the attacker may be able to steal the victim's authentication credentials and use them to access the victim's private information and/or complete any action that the victim is authorized to perform on that web site, or on other web sites in the same DNS domain that share authentication cookies.

Disclosure Timeline:
2008-05-13 Vulnerability discovered.
2008-05-14 Vendor notified.
2008-05-14 Initial vendor response.
2008-05-22 Vendor provided patch for version 4.0.4.
2008-05-23 Vendor provided patch for version 3.10.
2008-05-28 Vendor commented on draft of this disclosure.
2008-05-28 Public disclosure.

Disclaimer:
All information is thought to be correct as of the time of disclosure, however, this information is provided without any assurance as to its accuracy or reliability.

The purpose of this disclosure is to alert users who may be at risk, and empower them to test their own systems, with the goal of improving Internet security for all. It may be illegal to use this information to test systems you do not own.

You are responsible for what you do with this information. No one else accepts liability for what you do.

Credit: Discovered by Marvin Simkin.

About the author:
Marvin Simkin was one of several security researchers to independently discover "reflected" (type 1) XSS and participate in responsible disclosure in 1999. At the time of discovery, available statistics suggested that at least 95% of all web sites on the Internet were vulnerable.

-------------------------------------
Marvin Simkin
Manager of Information Technology
School of Earth and Space Exploration
Arizona State University
http://simkin.asu.edu/

Powered by blists - more mailing lists