Asserts considered harmful (or GMP spills its sensitive information)

[Jeffrey Walton]

The GMP library uses asserts to crash a program at runtime when
presented with data it did not anticipate. The library also ignores
user requests to remove asserts using Posix's -DNDEBUG. Asserts are a
debugging aide intended for developement, and using them in production
software ranges from questionable to insecure.

Many programs and libraries can safely use assert to crash a program
at runtime. However, the prequisite is, the program cannot handle
sensitive information like user passwords, user keys or sensitive
documents.

High integrity software, like GMP and Nettle, cannot safely use an
assert to crash a program. To understand why the data flow must be
examined. First, when an assert fires, abort() is called and a SIGABRT
is eventually sent to the program on Unix and Linux
(http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html).

Second, the SIGABRT terminates the process and can write a core file.
This is the first point of unwanted data egress. Sensitive information
like user passwords and keys can be written to the filesystem
unprotected.

Third, the dump is sometimes sent to an error reporting service like
Apple Crash Report, Android Crash Report, Ubuntu Apport, and Windows
Error Reporting. This is the second point of unwanted data egress. The
platform provider like Apple, Google, Microsoft or Ubuntu can gain
access to the sensitive information, in addition to the developer.

In fact, when one popular security library used in Bitcoin wallets was
apprised of the situation, they responded:

The standard abort() call also produces somewhat useful
error messages on Windows, so I can get an idea on what’s
going on when users report these.

Another popular security library used for code signing remarked:

Please never ever define NDEBUG. This is a severe misfeature
of the assert macro.

Wow, change your passwords and keys after an asert fires...

Here's a small example of triggering an assert using the Nettle
library. Nettle depends on GMP, and GMP is the root cause of the
information leak. The result below can be reproduced on i686, x86_64,
and Aarch64 using the attached script. ARM A-32 does not work at the
moment due to GMP build errors.

In the case below Nettle is using benign data and not maliciously
crafted data. Notice GMP spilled the sensitive information during a
sliding window modular exponentiation (also see
https://gmplib.org/repo/gmp-6.1/file/tip/mpn/generic/sec_powm.c).

# from Nettle 'make check'
...
PASS: rsa-keygen
PASS: rsa-sec-decrypt
sec_powm.c:293: GNU MP assertion failed: enb >= windowsize
../run-tests: line 57: 24756 Aborted (core dumped) "$1" $testflags
FAIL: rsa-compute-root
PASS: dsa
...
#!/usr/bin/env bash

CURR_DIR=$(pwd)
function finish {
  cd "$CURR_DIR"
}
trap finish EXIT

rm -rf /tmp/gmp-test

cd /tmp
wget https://ftp.gnu.org/gnu/gmp/gmp-6.1.2.tar.bz2 -O gmp-6.1.2.tar.bz2
tar -xjf gmp-6.1.2.tar.bz2
cd gmp-6.1.2

PKG_CONFIG_PATH="/tmp/gmp-test/lib/pkgconfig" \
CPPFLAGS="-I/tmp/gmp-test/include -DNDEBUG" \
CFLAGS="-g2 -O2 -march=native -fPIC" \
LDFLAGS="-L/tmp/gmp-test/lib -Wl,-R,/tmp/gmp-test/lib -Wl,--enable-new-dtags" \
./configure --prefix=/tmp/gmp-test

make
make check
make install

cd /tmp
wget https://ftp.gnu.org/gnu/nettle/nettle-3.4.1.tar.gz -O nettle-3.4.1.tar.gz
tar -xzf nettle-3.4.1.tar.gz
cd nettle-3.4.1

PKG_CONFIG_PATH="/tmp/gmp-test/lib/pkgconfig" \
CPPFLAGS="-I/tmp/gmp-test/include -DNDEBUG" \
CFLAGS="-g2 -O2 -march=native -fPIC" \
LDFLAGS="-L/tmp/gmp-test/lib -Wl,-R,/tmp/gmp-test/lib -Wl,--enable-new-dtags" \
./configure --prefix=/tmp/gmp-test

make
make check
make install

Re: [FD] Defense in depth -- the Microsoft way (part 51): Skype's home-grown updater allows escalation of privilege to SYSTEM

[Jeffrey Walton]

On Fri, Feb 9, 2018 at 1:01 PM, Stefan Kanthak  wrote:
> Hi @ll,
>
> since about two or three years now, Microsoft offers Skype as
> optional update on Windows/Microsoft Update.
>
> JFTR: for Microsoft's euphemistic use of "update" see
>   
>
> Once installed, Skype uses its own proprietary update mechanism
> instead of Windows/Microsoft Update: Skype periodically runs
> "%ProgramFiles%\Skype\Updater\Updater.exe"
> under the SYSTEM account.
> When an update is available, Updater.exe copies/extracts another
> executable as "%SystemRoot%\Temp\SKY.tmp" and executes it
> using the command line
> "%SystemRoot%\Temp\SKY.tmp" /QUIET
>
> This executable is vulnerable to DLL hijacking: it loads at least
> UXTheme.dll from its application directory %SystemRoot%\Temp\
> instead from Windows' system directory.
>
> An unprivileged (local) user who is able to place UXTheme.dll or
> any of the other DLLs loaded by the vulnerable executable in
> %SystemRoot%\Temp\ gains escalation of privilege to the SYSTEM
> account.
>
>
> The attack vector is well-known and well-documented as CAPEC-471:
> 
>
> Microsoft published plenty advice/guidance to avoid this beginner's
> error: ,
> ,
> 
> and
> 
> ... which their own developers and their QA but seem to ignore!
>
> See 
> for the same vulnerability in another Microsoft product!

Not sure if this is related, but:
https://winbuzzer.com/2018/02/14/microsoft-just-killed-skype-classic-response-unfixable-security-bug-xcxwbn/

Microsoft today squashed a bug that was found in Skype’s updater
process earlier this week. However, it seems the company’s method for
stopping the flaw is to kill off the Skype classic experience. If that
is the case, users of Skype on Windows 7 and Windows 8.1 could lose
access to the service.

As reported on Monday, a security vulnerability could give hackers
access to system-level privileges. If properly exploited, attackers
could use Skype as a backdoor to get full system rights and enter all
areas of an operating system.

In response, Microsoft said it was unable to fix the bug immediately
because it would require a lot of work. Indeed, the company said patch
the flaw would take a massive code rewrite. In other words, Microsoft
would need to overhaul the whole underpinning of the classic Skype
program.

It seems Microsoft found an alternative to rewriting code and fixing
Skype… the company has decided to effectively kill off the classic
app. The older version of Skype is no longer available anywhere as a
download.
...

CVE for Apple's ECDHE-ECDSA SecureTransport bug?

[Jeffrey Walton]

Does anyone know if Apple's ECDHE-ECDSA SecureTransport bug was
assigned a CVE? It affected OS X and iOS.

Effectively, the bug was an implementation error that cause
interoperability failures. To mostly counter it, the cipher suites had
to be disabled, which resulted in a loss of security. If the person
experiencing it did not know the cause, then they were left with a
Denial of Service (DoS).

To be clear, this was a different bug than CVE-2015-1130 (Goto Fail).

Also see SSL_OP_SAFARI_ECDHE_ECDSA_BUG on the OpenSSL wiki
(http://wiki.openssl.org/index.php/SSL_OP_SAFARI_ECDHE_ECDSA_BUG).

Hidden backdoor API to root privileges in Apple OS X

[Jeffrey Walton]

https://truesecdev.wordpress.com/2015/04/09/hidden-backdoor-api-to-root-privileges-in-apple-os-x/

The Admin framework in Apple OS X contains a hidden backdoor API to
root privileges. It’s been there for several years (at least since
2011), I found it in October 2014 and it can be exploited to escalate
privileges to root from any user account in the system.

The intention was probably to serve the “System Preferences” app and
systemsetup (command-line tool), but any user process can use the same
functionality.

Apple has now released OS X 10.10.3 where the issue is resolved. OS X
10.9.x and older remain vulnerable, since Apple decided not to patch
these versions. We recommend that all users upgrade to 10.10.3.
...

Re: [FD] [oss-security] Bug in bash = 4.3 [security feature bypassed]

[Jeffrey Walton]

 2014-06-03 16:16 GMT+02:00 Hector Marco hecma...@upv.es:

 Hi everyone,

 Recently we discovered a bug in bash. After some time after reporting
 it to bash developers, it has not been fixed.

 We think that this is a security issue because in some circumstances
 the bash security feature could be bypassed allowing the bash to be a
 valid target shell in an attack.

 We strongly recommend to patch your bash code.

 Why don't fix this bug by simple adding mandatory if clause ?
 Any comments about this issue are welcomed.


 Details at:
 http://hmarco.org/bugs/bash_4.3-setuid-bug.html
It looks like Rage Against The Cage has been rediscovered. Also known
as Android ADB Setuid bug.

Jeff

iOS: List of available trusted root certificates

[Jeffrey Walton]

From iOS: List of available trusted root certificates,
http://support.apple.com/kb/HT5012.

There's no reason to allow some of this to occur in 2013. As a
proxy-relying-party, Apple is responsible for this stuff because users
are not allowed to make the decisions or modify the Trust Store.

For reference:
Peter Gutmann, Engineering Security,
www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf‎
Baseline Certificate Requirements:
https://www.cabforum.org/Baseline_Requirements_V1_1_6.pdf
Extended Validation Certificate Requirements:
https://www.cabforum.org/Guidelines_v1_4_3.pdf

Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c)
1999 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 4
Public Primary Certification Authority - G3
Serial Number: ec:a0:a7:8b:6e:75:6a:01:cf:c4:7c:cc:2f:94:5e:d7
Missing Critical Basic Constraint and CA=TRUE

Subject: C=DK, O=TDC Internet, OU=TDC Internet Root CA
Serial Number: 986490188 (0x3acca54c)
Missing Critical Basic Constraint

Subject: CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet
Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1, C=TR, L=ANKARA, O=(c) 2005
T\xC3\x9CRKTRUST Bilgi \xC4\xB0leti\xC5\x9Fim ve Bili\xC5\x9Fim
G\xC3\xBCvenli\xC4\x9Fi Hizmetleri A.\xC5\x9E.
Serial Number: 1 (0x1)
Missing Critical Basic Constraint

Subject: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref.
(limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure
Server Certification Authority
Serial Number: 927650371 (0x374ad243)
Missing Critical Basic Constraint

Subject: C=CN, O=UniTrust, CN=UCA Root
Serial Number: 9 (0x9)
Missing Critical Basic Constraint

Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary
Certification Authority
Serial Number: 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Missing Critical Basic Constraint and CA=TRUE

Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary
Certification Authority
Serial Number: 3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
Missing Critical Basic Constraint and CA=TRUE

Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert
Class 2 Policy Validation Authority,
CN=http://www.valicert.com//emailAddress=i...@valicert.com
Serial Number: 1 (0x1)
Missing Critical Basic Constraint and CA=TRUE

Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For
authorized use only, OU=VeriSign Trust Network
Serial Number: 7d:d9:fe:07:cf:a8:1e:b7:10:79:67:fb:a7:89:34:c6
Missing Critical Basic Constraint and CA=TRUE

Subject: C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For
authorized use only, OU=VeriSign Trust Network
Serial Number: 32:88:8e:9a:d2:f5:eb:13:47:f8:7f:c4:20:37:25:f8
Missing Critical Basic Constraint and CA=TRUE

Subject: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing,
CN=StartCom Certification Authority
Serial Number: 1 (0x1)
Missing Critical Basic Constraint

Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert
Class 1 Policy Validation Authority,
CN=http://www.valicert.com//emailAddress=i...@valicert.com
Serial Number: 1 (0x1)
Missing Critical Basic Constraint and CA=TRUE

Subject: C=US, O=VeriSign, Inc., OU=Class 1 Public Primary
Certification Authority
Serial Number: cd:ba:7f:56:f0:df:e4:bc:54:fe:22:ac:b3:72:aa:55
Missing Critical Basic Constraint and CA=TRUE

Subject: C=US, O=VeriSign, Inc., OU=Class 1 Public Primary
Certification Authority
Serial Number: 3f:69:1e:81:9c:f0:9a:4a:f3:73:ff:b9:48:a2:e4:dd
Missing Critical Basic Constraint and CA=TRUE

Subject: C=CN, O=UniTrust, CN=UCA Global Root
Serial Number: 8 (0x8)
Missing Critical Basic Constraint

Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c)
1999 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 2
Public Primary Certification Authority - G3
Serial Number: 61:70:cb:49:8c:5f:98:45:29:e7:b0:a6:d9:50:5b:7a
Missing Critical Basic Constraint and CA=TRUE

Subject: C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DoD CLASS 3 Root CA
Serial Number: 4 (0x4)
Missing Critical Basic Constraint

Subject: C=KR, O=KISA, OU=Korea Certification Authority Central,
CN=KISA RootCA 3
Serial Number: 2 (0x2)
Missing Critical Basic Constraint and CA=TRUE

Subject: C=US, O=VeriSign, Inc., OU=Class 2 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For
authorized use only, OU=VeriSign Trust Network
Serial Number: b9:2f:60:cc:88:9f:a1:7a:46:09:b8:5b:70:6c:8a:af
Missing Critical Basic Constraint and CA=TRUE

Subject: C=TW, O=Chunghwa Telecom Co., Ltd., OU=ePKI Root
Certification Authority
Serial Number: 15:c8:bd:65:47:5c:af:b8:97:00:5e:e4:06:d2:bc:9d
Missing Critical Basic Constraint

Subject: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc.,
CN=GTE CyberTrust Global 

Re: [Full-disclosure] Defense in depth -- the Microsoft way (part 8): execute everywhere!

[Jeffrey Walton]

Hi Stefan,

 ... administrative rights for every user account
Hmmm... XP/x64 appears to have a bug such that the second user also
needs to be admin (perhaps XP/x86, too). XP does not recognize the
first account as admin, so the second account cannot be limited (at
least on my test box).

Vista and above make the first user admin, but others users default to standard.

Jeff

On Sat, Aug 24, 2013 at 5:32 PM, Stefan Kanthak stefan.kant...@nexgo.de wrote:
 Hi,

 since it's start about 20 years ago Windows NT supports (fine grained)
 ACLs, including the permission execute file.

 In their very finite wisdom Microsoft but decided back then to have
 this permission set on EVERY file a user creates (and assumes it is
 set on local and remote file systems which dont support ACLs).

 The result: on Windows, malware can run everywhere (and since CWD
 alias . is in the path, can be started everywhere)!


 These fundamental errors, combined with two other fundamental errors
 (NO ACLs on %SystemRoot% and %ProgramFiles% to prevent write access
 for non-administrative user accounts, and administrative rights for
 every user account) turned Windows NT into the same unsafe, insecure
 and vulnerable system its predecessors MS-DOS and Windows 3.x were
 and enabled miscreants to abuse internet-connected Windows systems
 to distribute SPAM, launch DDoS attacks, spread malware, etc.


 For a company that puts compatibility above all other criteria this
 decision might have looked reasonable ... BUT: it was NOT!


 Windows NT introduced the Win32-API, which is/was INCOMPATIBLE to the
 existing DOS- and Win16-API. To run existing applications written for
 the old APIs Windows NT introduced NTVDM (the Virtual DOS Machine)
 and WoW (the Windows on Windows subsystem); only these Windows NT
 components had to be made compatible (and unsafe enough to run old
 applications).

 There was ABSOLUTELY no need to sacrifice the safety and security of
 Windows NT and the Win32-API for the sake of compatibility: the
 Win32-API was new, no existing applications had to be supported!


 Then sloppy developers started to build their applications for the
 Win32-API of this unsafe/insecure environment ... and expected their
 unsuspecting victims^Wusers to have write access to %SystemRoot% and/or
 %ProgramFiles% to write their *.INI files, for example, or to run their
 crapware with administrative or power-user rights.


 JFTR: since many years Microsoft makes many (almost futile) attempts
 to mitigate the effect of their wrong design decision(s), for example:

 * http://support.microsoft.com/kb/269049 alias
   http://technet.microsoft.com/security/bulletin/ms00-052

 * http://support.microsoft.com/kb/306850

 * http://support.microsoft.com/kb/905890

 * http://support.microsoft.com/kb/953818 alias
   http://technet.microsoft.com/security/advisory/953818

 * http://support.microsoft.com/kb/959426 alias
   http://technet.microsoft.com/security/bulletin/ms09-015

 * http://support.microsoft.com/kb/2264107

 * http://support.microsoft.com/kb/2269637 alias
   http://technet.microsoft.com/security/advisory/2269637 PLUS the
   28(!) security bulletins listed there

 but NEVER tackled the source of the problem!


 Instead they introduced things like the security theatre UAC: with
 Windows 8 the user account(s) created during setup still have
 administrative rights. And Windows 7 introduced the silent elevation
 for about 70 of Microsoft own programs...


 stay tuned
 Stefan Kanthak


 PS: if you want to mitigate the wrong design decision that every file
 is executable: add and propagate an inheritable-only deny ACE
 with execute file permission for the user group WORLD\Everyone
 alias S-1-1-0, (D;OIIO;WP;;;WD) in SDDL notation, at least for
 %USERPROFILE% and %ALLUSERSPROFILE% alias %ProgramData%.

 On Windows NT 6.x, consider to add another deny ACE which prevents
 the directories/objects owner from changing/removing that permission:
 (D;;WDAC;;;OW) in SDDL notation.

 Since this mitigation will stop Administrators and LocalSystem
 to run files in their user profiles (to be precise: in %TEMP%
 alias %USERPROFILE%\Local Settings\Application Data\TEMP resp.
 %USERPROFILE%\AppData\TEMP where self-extracting installers will
 typically unpack and execute their payload) you'll have to remove
 the user environment variables TEMP and TMP of these user accounts
 (setting the system environment variables TEMP and TMP which point
 to %SystemRoot%\TEMP into effect).


 See the script http://home.arcor.de/skanthak/download/~EXECUTE.INF
 for a POC (targetting Windows NT 5.x). It sets the deny ACE also
 on subordinate directories which are exempt from ACL inheritance,
 as well as some of the user-writable subdirectories of %SystemRoot%
 which dont host executable files.

 WARNING: unfortunately the (only) Microsoft utility which allows to
 add the specific ACEs, ICACLS.EXE, used in 

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[Jeffrey Walton]

On Mon, Aug 12, 2013 at 1:28 PM, Coderaptor coderap...@gmail.com wrote:
 I have been a silent spectator to this drama, and could not resist adding a 
 few thoughts of my own:

 1. All software, especially webservers, should ship with secure defaults. 
 Period. It is a fundamental mistake to assume all admins who roll out web 
 apps and maintain servers RTFM before rolling out. The key idea here is time 
 to market, and there is huge amount of data to prove this.

+1. All software should be shipped secure out of the box. Its
amazing so many folks keep making the same mistakes from the 1980s and
1990s.

 ...
 Huge amount of software today is turd polishing, open source no exception 
 (though it is supposed to have better track record). The blame lies squarely 
 on everyone.

The more eyes the better theory is hogwash. I cringe when I hear
anyone discussing the security of crowd sourcing. There's two problems
with their arguments: first is Cognitive Biases, and second is the
Bystander Effect. The biases are being demonstrated by NB and RH, and
its results are typical (no offense NB and RH). The Bystander Effect
ensures that the more people see a bug, the less likely they are going
to do anything about it because they believe someone else has already
done something.

They are well known problems in Security Engineering. See Peter
Gutmann's Engineering Security
(www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf‎) or Ross Anderson's
Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html).

Jeff

 On Aug 11, 2013, at 3:30 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 11.08.2013 23:56, schrieb Stefan Kanthak:
 Reindl Harald h.rei...@thelounge.net wrote:
 again:
 symlinks are to not poision always and everywhere
 they become where untrusted customer code is running
 blame the admin which doe snot know his job and not
 the language offering a lot of functions where some
 can be misused

 Again: symlinks are well-known as attack vector for years!

 and that's why any admin which is not clueless
 disables the symlink function - but there exists
 code which *is* secure, runs in a crontrolled
 environment and make use of it for good reasons

 It's not the user/administrator who develops or ships insecure code!

 but it's the administrator which has the wrong job if
 create symlinks is possible from any random script
 running on his servers

 anyways, i am done with this thread

 the topic is *not* Apache suEXEC privilege elevation it
 is admins not secure their servers - period

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[Jeffrey Walton]

On Sat, Aug 10, 2013 at 6:10 AM, Gichuki John Chuksjonia
chuksjo...@gmail.com wrote:
 One thing u gotta remember most of the Admins who handle webservers in
 a network are also developers since most of the organizations will
 always need to cut on expenses, and as we know, most of the developers
 will just look into finishing work and making it work. So if something
 doesn't run due to httpd.conf, you will find these guys loosening
 server security, therefore opening holes to the infrastructure.
Cognitive Bias and Dissonance are well known problems in security
engineering. NB's comments are a testament to the disconnect between
the creators of the system and the users of the system. (No offense to
NB).

See, for example, Peter Gutmann's Engineering Security
(www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf‎) or Ross Anderson's
Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html).

Jeff

Re: [Full-disclosure] [SE-2012-01] New Reflection API affected by a known 10+ years old attack

[Jeffrey Walton]

On Thu, Jul 18, 2013 at 12:50 AM, Security Explorations
cont...@security-explorations.com wrote:

 Hello All,

 We discovered yet another indication that new Reflection API introduced
 into Java SE 7 was not a subject to a thorough security review (if any).
I'm kind or surpised some of these bugs exist for so long. Allowing
them to fester and rot can't be good (I have not been able to come up
with a use case where it is desired or preferred).

Does anyone know anything about Oracle's engineering process? What is
Oracle doing to ensure issues are tracked and remediated in reasonable
time? What does the process include for code scanning to catch low
hanging fruit? Are they using Find Bugs or Coverity (I checked
scan.coverity.com, and I did not see Oracle Java or OpenJDK listed, so
I wonder if they are doing it internally). What is the QA process
doing to ensure items with negative impact are not allowed to pass?

Jeff

Re: MiniUPnPd Information Disclosure (CVE-2013-2600)

[Jeffrey Walton]

On Fri, Jul 12, 2013 at 2:16 PM,  cyo...@tripwire.com wrote:
 ...

 This issue was addressed on April 26, 2013 as noted in the changelog: 
 http://miniupnp.free.fr/files/changelog.php?file=miniupnpd-1.8.20130607.tar.gz

 2013/04/26:
   Correctly handle truncated snprintf() in SSDP code

 The problem is illustrated in the following code snippet:
 Minissdp.c:
 203 static void SendSSDPAnnounce2(int s, struct sockaddr_in sockname,
 204   const char * st, int st_len,
 205   const char * host, unsigned short port)
 206 {
 207 int l, n;
 208 char buf[512];
 209 /* TODO :
 210  * follow guideline from document UPnP Device Architecture 1.0
 211  * put in uppercase.
 212  * DATE: is recommended
 213  * SERVER: OS/ver UPnP/1.0 miniupnpd/1.0
 214  * */
 215 l = snprintf(buf, sizeof(buf), HTTP/1.1 200 OK\r\n
 216 Cache-Control: max-age=120\r\n
 217 ST: %.*s\r\n
 218 USN: %s::%.*s\r\n
 219 EXT:\r\n
 220 Server:  MINIUPNPD_SERVER_STRING \r\n
 221 Location: http://%s:%u; ROOTDESC_PATH \r\n
 222 \r\n,
 223 st_len, st,
 224 uuidvalue, st_len, st,
 225 host, (unsigned int)port);
 226 n = sendto(s, buf, l, 0,
 227(struct sockaddr *)sockname, sizeof(struct sockaddr_in) );
 228 #if 0 //JM: Don't fill up syslog, even in error condition
 229 if(n0)
 230 {
 231 syslog(LOG_ERR, sendto: %m);
 232 }
 233 #endif
 234 }


 Notice that the sendto on line 226 is using the snprintf return value, l, 
 from line 215 without considering whether l  sizeof(buf) as is the case when 
 the buffer is truncated.
Truncation occurs at l = sizeof(buf) since because of the terminating NULL.

Jeff

Apple and Wifi Hotspot Credentials Management Vulnerability

[Jeffrey Walton]

This vulnerability was published to the OWASP Mobile Security list as
a research paper by Andreas Kurtz, Daniel Metz and Felix Freiling. See
Cracking iOS personal hotspots using a Scrabble crossword game word
list, 
http://lists.owasp.org/pipermail/owasp-mobile-security-project/2013-June/000640.html.

It appears Apple Wifi hotspot passwords are generated using a wordlist
consisting of 1842 words. The authors built a customer cracker to aide
in recovery of the Wifi hotspot passwords.

The paper's homepage can be found at https://www1.cs.fau.de/hotspot.
The paper does not offer a CWE classification or CVE at this point in
time.

Re: Apple and Wifi Hotspot Credentials Management Vulnerability

[Jeffrey Walton]

On Mon, Jun 17, 2013 at 3:35 PM, Jeffrey Walton noloa...@gmail.com wrote:

 ...
 It appears Apple Wifi hotspot passwords are generated using a wordlist
 consisting of 1842 words. The authors built a customer cracker to aide
 in recovery of the Wifi hotspot passwords.
My bad. The application estimates the time to crack the password used.
It does not attempt to recover the password.

Re: Report OWASP WAF Naxsi bypass Vulnerability

[Jeffrey Walton]

Tracked through issue 65
(http://code.google.com/p/naxsi/issues/detail?id=65), fixed at
check-in R545 (http://code.google.com/p/naxsi/source/detail?spec=svn545r=545).

On Mon, Mar 25, 2013 at 10:00 PM,  saf...@gmail.com wrote:
 OWASP WAF Naxsi bypass Vulnerability

 Certain unspecified input is not properly handed in
 naxsi_src/naxsi_utils.c naxsi_unescape_uri(u_char **dst, u_char **src,
 size_t size, ngx_uint_t type) before being used to filtered. This can
 be exploited to bypass some WAF rules.

 Naxsi site
 https://code.google.com/p/naxsi/

 Affected
 All the version

 My site
 http://safe3.com.cn/

 My nick name is Safe3

 It happens like that,the naxsi_unescape_uri function process the % url
 decode,if the next char after the % is a hex char and not after the
 hex char,then it will drop the % and the next char.So if we input a
 sql keyword s%elect,it will come to slect instead,this is not the
 standard url decode way.Such as the IIS asp,it will process the
 s%elect as a result of select,so we can bypass some
 WAF rules just like that.

 I afford a standard url decode function patch as the follow to fix this issue:
 ...

Re: [Full-disclosure] MySQL (Linux) Heap Based Overrun PoC Zeroday

[Jeffrey Walton]

Hi Kingcope,

# As seen below $edx and $edi are fully controlled,
# the current instruction is
# = 0x83a6b24 free_root+180:   mov(%edx),%edi
# this means we landed in a place where 4 bytes can be controlled by 4 bytes
# with this function pointers and GOT entries can be rewritten to
execute arbritrary code

Out of curiosity, is this exploitable when using hardened toolchain
settings? Specifically, -z,noexecheap, -z,now, and -z,relro? For
no-exec heaps., you need to be on Gentoo or other platforms which
offer the remediation.

Jeff

On Sat, Dec 1, 2012 at 4:26 PM, king cope
isowarez.isowarez.isowa...@googlemail.com wrote:
 (see attachment)

 Cheerio,

 Kingcope

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

Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday

[Jeffrey Walton]

Hi Kingcope,

   MySQL Server exploitable stack based overrun
   Ver 5.5.19-log for Linux and below (tested with Ver 5.1.53-log
   for suse-linux-gnu too) unprivileged user (any account
   (anonymous account?), post auth) as illustrated below the
   instruction pointer is overwritten with 0x41414141 bug found by
   Kingcope this will yield a shell as the user 'mysql' when properly
   exploited

Out of curiosity, is this exploitable when using hardened toolchain
settings? Specifically, -D_FORTIFY_SOURCES=2 and
-fstack-protector-all?

Jeff

On Sat, Dec 1, 2012 at 4:26 PM, king cope
isowarez.isowarez.isowa...@googlemail.com wrote:
 (see attachment)

 Cheerio,
 Kingcope

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

Re: [Full-disclosure] [SE-2012-01] information regarding recently discovered Java 7 attack

[Jeffrey Walton]

Hi,

 found as part of our SE-2012-01 Java SE security research project [3].
Well, it seems Oracle did not feel the issues Security Explorations
shared were a priority. Blogging about these things has not produced
optimal results either.

Have you reported the issues to US Cert?

Will you be disclosing details on Bugtraq/Full Disclosure?

Jeff

On Tue, Aug 28, 2012 at 9:22 AM, Security Explorations
cont...@security-explorations.com wrote:

 Hello All,

 This post is made in reference to recently discovered attack against
 Java SE 7 platform [1][2]. We discovered that the vulnerabilities used
 by the attack code are similar to some of the weaknesses that we have
 found as part of our SE-2012-01 Java SE security research project [3].

 The recently reported Java attack relies on a couple of issues, which
 are briefly described below.

 [Vuln 1]
 The first vulnerability stems from the fact that it is possible
 to obtain references to restricted classes such as those coming
 from a sun.* package.

 The weakness has its origin in com.sun.beans.finder.ClassFinder
 class and its findClass method. The bug is caused by insecure
 usage of reflective forName call of java.lang.Class class.

 We reported what seems to be an instance of Vuln 1 to Oracle in Apr
 2012 (Issue 11). In our report describing Issue 11 we demonstrated
 a successful loading of a sun.awt.SunToolkit class by the means
 of a findClass method of ClassFinder class. We however did associate
 this behavior with a slightly different cause.

 [Vuln 2]
 The second vulnerability relies on the possibility to obtain
 references to methods of restricted classes. It has its origin
 in findMethod method of com.sun.beans.finder.MethodFinder class.
 The bug is caused by insecure usage of reflective getMethod call
 of java.lang.Class class.

 Vuln 2 was reported to Oracle in Apr 2012 (Issue 16).

 Insecure ClassFinder and MethodFinder classes were introduced in
 Java 7. Among other things, this has lead to the modification of
 java.beans.Statement class implementation. Java 6 implementation
 of the aforementioned class seems to be more secure as it relies
 on a ReflectionUtils class introduced at the time of fixing the
 vulnerabilities reported to Sun Microsystems back in 2005 [4].

 [Exploit vector]
 The exploit vector for the reported code relies on sun.awt.Suntoolkit
 class and the ability to call its getField method. This method allows
 to obtain privileged (with override field set to true) references to
 private fields of arbitrary classes (including restricted ones).

 Exploit vector relying on sun.awt.SunToolkit class and its getField
 method was reported to Oracle in Apr 2012. We demonstrated full JVM
 sandbox bypass by abusing SunToolkit class implementation, but in
 a different way than it is done in a circulating code. Again, Java 6
 implementation of SunToolkit class seems to be more secure as its
 getField method is defined to be private (it is public in Java 7).

 The reported attack code will not work in Java 6 environment for the
 reasons described above. Although, Java 7 adoption might not be high
 yet, with the release of Java SE 7 Update 4, Java SE 7 runtime is the
 default JRE [5].

 On 23 Aug 2012, Oracle provided us with a monthly status report for
 the security issues reported to the company earlier this year. The
 company informed us that 19 of the remaining 25 issues were fixed in
 main codeline and that they are scheduled for a future CPU. This
 include fixes for some of the issues (11 and 16) that are used by
 the attack code recently revealed.

 We plan to release a short technical paper presenting the results of
 our Java SE security research after Oracle releases their next Java
 SE CPU (scheduled for Oct 2012) and most serious issues get fixed.

 Thank you.

 Best Regards,
 Adam Gowdiak

 -
 Security Explorations
 http://www.security-explorations.com
 We bring security research to the new level
 -

 References:
 [1] Zero-Day Season is Not Over Yet

 http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html#more
 [2] Let's start the week with a new Java 0-day in Metasploit

 https://community.rapid7.com/community/metasploit/blog/2012/08/27/lets-start-the-week-with-a-new-java-0day
 [3] SE-2012-01 Security vulnerabilities in Java SE
  http://www.security-explorations.com/en/SE-2012-01.html
 [4] Sun Alert 200688
  http://download.oracle.com/sunalerts/1000543.1.html
 [5] Moving to Java 7 as default
  https://blogs.oracle.com/henrik/entry/moving_to_java_7_as

Fwd: [cryptography] Apple Legacy filevault barn door...

[Jeffrey Walton]

Interesting reading from the cryptography mailing list

-- Forwarded message --
From: David I. Emery d...@dieconsulting.com
Date: Fri, May 4, 2012 at 8:40 PM
Subject: [cryptography] Apple Legacy filevault barn door...
To: cryptogra...@randombit.net

       As someone said here recently, carefully built crypto has a
unfortunate tendency to consist of three thick impregnable walls and a
picket fence in the back with the gate left open.

       That seems to have happened to Apple's older (legacy)
Filevault in the current release of MacOX Lion (10.7.3) something
intended to protect sensitive information stored on laptops by providing
for encrypted user home directories contained in an encrypted file
system mounted on top of the user's home directory.

       Someone, for some unknown reason, turned on a debug switch
(DEBUGLOG) in the current released version of MacOS Lion 10.7.3 that
causes the authorizationhost process's HomeDirMounter DIHLFVMount to log
in *PLAIN TEXT* in a system wide logfile readible by anyone with root or
admin access the login password of the user of an encrypted home
directory tree (legacy Filevault).

       The log in question is kept by default for several weeks...

       Thus anyone who can read files accessible to group admin can
discover the login passwords of any users of legacy (pre LION) Filevault
home directories who have logged in since the upgrade to 10.7.3 in early
February 2012.

       This is worse than it seems, since the log in question can also
be read by booting the machine into firewire disk mode and reading it by
opening the drive as a disk or by booting the new-with-LION recovery
partition and using the available superuser shell to mount the main file
system partition and read the file.   This would allow someone to break
into encrypted partitions on machines they did not have any idea of any
login passwords for.

       One can partially protect oneself against the firewire disk and
recovery partition attacks by using Filevault 2 (whole disk encryption)
which then requires one know at least one user login password before one
can access files on the main partition of the disk.

       And one can provide further weaker protection by setting a
firmware password which must be supplied before one can boot the
recovery partition, external media, or enter firewire disk mode  -
though there is a standard technique for turning that off known to Apple
field support (genius bar) persons.

       But having the password logged in the clear in an admin readible
file *COMPLETELY*  breaks a security model - not uncommon in families -
where different users of a particular machine are isolated from each
other and cannot access each others files or login as each other with
some degree of assurance of security.   Granted, of course that someone
able to alter executable code could plant keyloggers and the like... and
break this ... but actually shipping product that does so without notice
is disturbing.

       And for those who use Apple's easy backup tools (Time
Capsule), it was possible to assume that those tools only wrote copies
of the  sparsebundle encrypted container for a Filevault legacy home
directory to the backup media meaning that an unencrypted backup would
still provide  protection for the contained encrypted home
directories... but with the password required to decrypt the
sparebundles stored in the clear on the (unencrypted) backup that
assumption is no longer true.

       One wonders why such a debug switch exists in shipped production
code... clearly it could be invoked covertly in specific situations, this
seems to be an example of someone turning it on for the entire release
by accident.

       Nobody breaks encryption by climbing the high walls in front...
when the garden gate is open for millions of machines.

       This bug (LEA feature?) seems to have been introduced into MacOS
Lion 10.7.3   early February 2012 and so far has not been corrected
by any updates.
...

Ubuntu, Linux Mint, and the Guest Account

[Jeffrey Walton]

I know there's not much new here, but I am amazed that Ubuntu, Linux
Mint and friends ship with a Guest account present and enabled.

The Guest account is surreptitiously added through a lightdm
configuration file, and is not part of the standard user database.
Because its not part of the standard user database, it can't be
disabled through /etc/shadow, nor disable it through familiar tools
such as userdel and usermod. Additionally, the damn account does not
show up in distribution provided tools such as User Accounts applet.

To make matters worse, grepping for guest returns 0 results because
lightdm.conf does not mention one must add the following to disable
the guest account (nothing is required to enable the account):

allow-guest=false

To add insult to injury, the Guest account is not sandboxed and user
home directories lack sufficient ACLs, so the guest account is able to
wander through user's home directories:

guest-dojMxl@vb-mint-12-x64 ~ $ pwd
/tmp/guest-dojMxl
guest-dojMxl@vb-mint-12-x64 ~ $ whoami
guest-dojMxl
guest-dojMxl@vb-mint-12-x64 /home/jwalton $ cd /home/
guest-dojMxl@vb-mint-12-x64 /home $ ls -al
total 12
drwxr-xr-x  3 rootroot4096 2012-05-05 16:29 .
drwxr-xr-x 23 rootroot4096 2012-05-05 16:32 ..
drwxr-xr-x  5 jwalton jwalton 4096 2012-05-05 16:35 jwalton
guest-dojMxl@vb-mint-12-x64 ~ $ cd /home/jwalton/
guest-dojMxl@vb-mint-12-x64 /home/jwalton $ ls -al
total 28
drwxr-xr-x 5 jwalton jwalton 4096 2012-05-05 16:35 .
drwxr-xr-x 3 rootroot4096 2012-05-05 16:29 ..
-rw-r--r-- 1 jwalton jwalton  220 2012-05-05 16:29 .bash_logout
drwx-- 3 jwalton jwalton 4096 2012-05-05 16:35 .cache
drwxr-xr-x 3 jwalton jwalton 4096 2012-05-05 16:29 .config
drwxr-xr-x 4 jwalton jwalton 4096 2012-05-05 16:29 .mozilla
-rw-r--r-- 1 jwalton jwalton  675 2012-05-05 16:29 .profile
...

 Is there any reason a KIOSK-like account is enabled by default? Do
KIOSKs really dominate the desktop market to warrant the account out
of the box?

Re: [Full-disclosure] pidgin OTR information leakage

[Jeffrey Walton]

On Mon, Feb 27, 2012 at 3:21 PM, Rich Pieri rati...@mit.edu wrote:
 On Feb 27, 2012, at 2:37 PM, Michele Orru wrote:
 I think you didn't understood the content of the advisory.
 If there are 10 non-root users in an Ubuntu machine for example,
 if user 1 is using pidgin with OTR compiled with DBUS, then user 2 to 10
 can see what user 1 pidgin conversation.


 This is not what the OP or CVE describe:

 plaintext. This makes it possible for attackers that have gained
 user-level access on a host, to listen in on private conversations
 associated with the victim account.

 Which I read as: if I compromise user1's account then I can snoop user1's 
 DBUS sessions.  It says nothing about me being able to snoop user2's 
 sessions.  The leading phrase about attackers gaining user-level access 
 implies that legitimate users on a system are not a relevant issue.

I tend to agree with you, and question if that is in fact true (it may
well be, my apologies in advance). DBUS is on my list of things to
probe, prod, and attatck due to data sharing.

But I'd be really surprised if data was available across distinct user
sessions. Unix/Linux are usually very good a separating processes and
sessions so that data does not comingle.

Jeff

Re: [Full-disclosure] Microsoft's Binary Planting Clean-Up Mission

[Jeffrey Walton]

On Thu, Sep 15, 2011 at 7:11 PM, Michael Schmidt mschm...@drugstore.com wrote:
 Someone’s just not reading the bulletins – Note the term “Remote” –
 including webdav, so a share that could be fully controlled by the
 exploiter. At least that is what I am understanding.



 Updates released on September 13, 2011

 Microsoft Security Bulletin MS11-071, Vulnerability in Windows Components
 Could Allow Remote Code Execution, provides support for vulnerable
 components of Microsoft Windows that are affected by the Insecure Library
 Loading class of vulnerabilities described in this advisory.

 Microsoft Security Bulletin MS11-073, Vulnerabilities in Microsoft Office
 Could Allow Remote Code Execution, provides support for vulnerable
 components of Microsoft Office that are affected by the Insecure Library
 Loading class of vulnerabilities described in this advisory.

In addition, this looks like it could be ripe for abuse (if it is true):
   Even more interesting is the fact that you can specify a
   UNC path in the import section of the PE file. If we specify
   \\66.93.68.6\z as the name of the imported DLL, the Windows
   loader will try to download the DLL file from our web server.

See http://www.phreedom.org/solar/code/tinype/.

 From: full-disclosure-boun...@lists.grok.org.uk
 [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of adam
 Sent: Thursday, September 15, 2011 3:27 PM
 To: secur...@acrossecurity.com
 Cc: full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com
 Subject: Re: [Full-disclosure] Microsoft's Binary Planting Clean-Up Mission



I'm afraid you don't fully understand the issue. This is not about placing
 your own
DLL on a local machine so that a chosen application will load it (i.e.,
 user
attacking an application on his own computer).



 I'm not sure you understood the point. That being, whether the user
 knowingly or unknowingly loads the malicious DLL - the application will be
 effected the same either way. To that point: it's been possible for over a
 decade (and perhaps even longer) so pretending that it's some brand new
 threat that needs to be dealt with immediately is foolish.



possibly on a remote share - and executing its code (i.e., attacker with
 zero
privileges on user's computer executing code on that computer).



 Zero privileges? So having write access to a share that the user
 accesses/loads files from - what do you call that? This is a social
 engineering attack - absolutely nothing more.



 On a related note: have you also contacted Linus about LD_PRELOAD?



 On Thu, Sep 15, 2011 at 5:05 PM, ACROS Security Lists li...@acros.si
 wrote:

 Hi Adam,

 I'm afraid you don't fully understand the issue. This is not about placing
 your own
 DLL on a local machine so that a chosen application will load it (i.e., user
 attacking an application on his own computer). It is about an application
 running
 on your computer silently grabbing a malicious DLL from attacker-controlled
 location
 - possibly on a remote share - and executing its code (i.e., attacker with
 zero
 privileges on user's computer executing code on that computer).

 I hope this helps a little.

 Cheers,
 Mitja


 -Original Message-
 From: iaretheb...@gmail.com [mailto:iaretheb...@gmail.com] On
 Behalf Of adam
 Sent: Thursday, September 15, 2011 11:26 PM
 To: Thor (Hammer of God)
 Cc: secur...@acrossecurity.com; Christian Sciberras;

 full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com

 Subject: Re: [Full-disclosure] Microsoft's Binary Planting

 Clean-Up Mission

 Plus: pretending that you're on the same page as Microsoft
 (from a security standpoint) to further your own argument is
 more damaging than it is beneficial. The entire binary
 planting concept was flawed from the very beginning. If you
 can drop a binary file on a user's machine - make it an
 executable and be done with it. There's nothing fancy or
 innovative about forcing applications to use specific DLLs -
 script kiddies have been doing it for over 10 years to inject
 custom code in multiplayer games.

 On Thu, Sep 15, 2011 at 3:59 PM, Thor (Hammer of God)
 t...@hammerofgod.com wrote:


       I'm curious.  Who is your contact at MSFT?  Who is it
 that has told you they have a Binary Planting Clean-up
 Mission and where do they mention you as having anything to
 do with it?

       If you are going to claim MSFT's actions as substantive
 to your agenda, how about provide some details?

       t

        -Original Message-
        From: ACROS Security Lists [mailto:li...@acros.si]
        Sent: Thursday, September 15, 2011 1:41 PM
        To: 'Christian Sciberras'
        Cc: Thor (Hammer of God); full-disclos...@lists.grok.org.uk;
        bugtraq@securityfocus.com

        Subject: RE: [Full-disclosure] Microsoft's Binary
 Planting Clean-Up Mission
       

        Hey Chris,
       
         I bet Microsoft actually like stating they just
 fixed yet another
         severe bug.
         Zero-day 

Re: Vulnerabilities in trading and SCADA softwares

[Jeffrey Walton]

On Wed, Sep 14, 2011 at 5:13 AM,  fergal.cass...@measuresoft.com wrote:

Please take this constructively...

 The so called vulnerability in ScadaPro does not apply when the Windows 
 firewall is enabled and under normal circumstances the TCP-IP port is not 
 used to communicate with the ScadaPro service.
Measuresoft should not stake its security on the hopes that a firewall
is running. There will be plenty of folks who will do dumb things with
it.

 In the next release of ScadaPro the TCP/IP port will not be available and 
 instead a secure web service will be available.

 Also please note these tests were performed independently of Measuresoft on a 
 demo version and without seeking or obtaining any advice from Measuresoft on 
 how to securely deploy ScadaPro.
Measuresoft should be deploying securely out of the box. Require the
user make manual changes to punch holes in the firewall (or do it for
them after they answer a yes/no with no as the default). Secure out of
the box is a good thing, even if it causes a few immediate hardships.

Jeff

Ubuntu: reseed(8), random.org, and HTTP request

[Jeffrey Walton]

Ubuntu's reseed(8) can be used to seed the PRNG state of a host. The
script is run when the package installed, and anytime su executes the
script.

reseed(8) performs a unsecured HTTP request to random.org for its
bits, despite random.org offering HTTPS services.

The Ubuntu Security Team took no interest when contacted by email (no
reply); the point of contact listed in the man pages took no interest
when contacted by email (no reply); and a launcher bug report was not
acted upon (https://bugs.launchpad.net/ubuntu/+source/reseed/+bug/804594).

Re: Perfect PDF products distributed with vulnerable MSVC++ libraries

[Jeffrey Walton]

On Tue, Jun 21, 2011 at 7:22 AM, Brad Hards br...@frogmouth.net wrote:
 On Sunday 19 June 2011 11:37:33 Stefan Kanthak wrote:
 soft Xpansion www.soft-xpansion.com distributes their (freeware)
 products Perfect PDF 7 Master and Perfect PDF 7 Reader (the
 current files are dated 2011-05-10) with OUTDATED and VULNERABLE
 Visual C++ 2008 runtime libraries VCRedist_x86.exe/VCRedist_x64.exe
 version 9.0.30729.17 of 2008-08-08.

 These libraries have been updated since then at least twice due to
 vulnerabilities, see
 http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx
 and
 http://www.microsoft.com/technet/security/bulletin/MS11-025.mspx
 Did you check if these vulnerabilities be exploited via this product? I'm not
 suggesting that its OK to distribute outdated libs, just to understand the
 risk a little more.
You need to worry about more than just this product. If an attacker
launches a vulnerable executable for which he has a vector (not
necessarily this product), all he/she needs to do is set the current
directory to the location of the flawed DLL. I believe it would
succeed because so few actually set SafeDllSearchMode to enabled (from
my auditing experience). See
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx.

Jeff
Jeff

Re: OpenBSD CARP Hash Vulnerability

[Jeffrey Walton]

On Fri, Dec 17, 2010 at 10:08 PM, Sam Banks wol...@ontogeny.ac.nz wrote:
 Hello Bugtraq,

 I disclosed this bug to the BSDs and no one is interested in fixing it
 so here you go. The two files attached are as follows:

 [SNIP]

 The OpenBSD CARP implementation (and all derivatives, such as FreeBSD
 and NetBSD) fails to include all fields contained in the carp_header
 structure[1] when calculating the SHA1 HMAC hash of the packet in the
 function carp_proto_input_c[2]. The two 8-bit fields not included in
 the hash generation are carp_advskew and carp_advbase. Among other
 functions, the fields are both set to 255 by the master CARP node to
 indicate that it wants to step down from the master role.
Analysis of the SSL 3.0 Protocol by Schneier and Wagner comes to mind.

3.6 The Horton principle

Let’s recall the ultimate goal of message authentication. SSL provides
message integrity protection just when the data passed up from the
receiver’s SSL record layer to the protected application exactly
matches the data uttered by the sender’s protected application to the
sender’s SSL record layer. This means, approximately, that it is not
enough to ap- ply a secure MAC to just application data as it is
transmitted over the wire—one must also authenti- cate any context
that the SSL mechanism depends upon to interpret inbound network data.
For lack of a better name, let’s call this “the Horton principle”
(with apologies to Dr. Seuss) of semantic authentication: roughly
speaking we want SSL to
“authenticate what was meant, not what was said.”
To phrase it another way,
Eschew unauthenticated security-critical context.

This design principle is hardly original; Abadi and Needham [AN96]
gave a version of it in the context of building secure protocols. The
Horton principle is essentially a restatement of their Principle 1 in
terms of requirements for record-layer message authentication.

[SNIP]

iwconfig and recent patches?

[Jeffrey Walton]

Hi All,

I was reading http://security.ece.cmu.edu/aeg/aeg-current.pdf. Is
anyone aware of recent patches to iwconfig for a buffer overrun? I did
not find any recent CVEs covering iwconfig.

Jeff

Re: 3rd party patch for XP for MS09-048?

[Jeffrey Walton]

Hi Susan,

 Read the bulletin.  There's no patch.  It is deemed by Microsoft to be of
 low impact and thus no patch has been built.
I don't know how I missed that XP/SP2 and above were not being
patched. It appears that my two references are worhtless... I used to
use them in position papers!
* http://support.microsoft.com/gp/lifepolicy
* http://support.microsoft.com/gp/lifeselect

Jeff

On Tue, Sep 15, 2009 at 5:24 PM, Susan Bradley sbrad...@pacbell.net wrote:
 Read the bulletin.  There's no patch.  It is deemed by Microsoft to be of
 low impact and thus no patch has been built.

 Jeffrey Walton wrote:

 Hi Aras,



 Given that M$ has officially shot-down all current Windows XP users by
 not
 issuing a patch for a DoS level issue,


 Can you cite a reference?

 Unless Microsoft has changed their end of life policy [1], XP should
 be patched for security vulnerabilities until about 2014. Both XP Home
 and XP Pro's mainstream support ended in 4/2009, but extended support
 ends in 4/2014 [2]. Given that we know the end of extended support,
 take a look at bullet 17 of [1]:

    17. What is the Security Update policy?

    Security updates will be available through the end of the Extended
    Support phase (five years of Mainstream Support plus five years of
    the Extended Support) at no additional cost for most products.
    Security updates will be posted on the Microsoft Update Web site
    during both the Mainstream and the Extended Support phase.



 I realize some of you might be tempted to relay the M$ BS about not
 being
 feasible because it's a lot of work rhetoric...


 Not at all.

 Jeff

 [1] http://support.microsoft.com/gp/lifepolicy
 [2] http://support.microsoft.com/gp/lifeselect

 On Tue, Sep 15, 2009 at 2:46 PM, Aras Russ Memisyazici
 nowh...@devnull.com wrote:


 Hello All:

 Given that M$ has officially shot-down all current Windows XP users by
 not
 issuing a patch for a DoS level issue, I'm now curious to find out
 whether
 or not any brave souls out there are already working or willing to work
 on
 an open-source patch to remediate the issue within XP.

 I realize some of you might be tempted to relay the M$ BS about not
 being
 feasible because it's a lot of work rhetoric... I would just like to
 hear
 the thoughts of the true experts subscribed to these lists :)

 No harm in that is there?

 Aras Russ Memisyazici
 Systems Administrator
 Virginia Tech

Re: 3rd party patch for XP for MS09-048?

[Jeffrey Walton]

Hi Aras,

 Given that M$ has officially shot-down all current Windows XP users by not
 issuing a patch for a DoS level issue,
Can you cite a reference?

Unless Microsoft has changed their end of life policy [1], XP should
be patched for security vulnerabilities until about 2014. Both XP Home
and XP Pro's mainstream support ended in 4/2009, but extended support
ends in 4/2014 [2]. Given that we know the end of extended support,
take a look at bullet 17 of [1]:

17. What is the Security Update policy?

Security updates will be available through the end of the Extended
Support phase (five years of Mainstream Support plus five years of
the Extended Support) at no additional cost for most products.
Security updates will be posted on the Microsoft Update Web site
during both the Mainstream and the Extended Support phase.

 I realize some of you might be tempted to relay the M$ BS about not being
 feasible because it's a lot of work rhetoric...
Not at all.

Jeff

[1] http://support.microsoft.com/gp/lifepolicy
[2] http://support.microsoft.com/gp/lifeselect

On Tue, Sep 15, 2009 at 2:46 PM, Aras Russ Memisyazici
nowh...@devnull.com wrote:
 Hello All:

 Given that M$ has officially shot-down all current Windows XP users by not
 issuing a patch for a DoS level issue, I'm now curious to find out whether
 or not any brave souls out there are already working or willing to work on
 an open-source patch to remediate the issue within XP.

 I realize some of you might be tempted to relay the M$ BS about not being
 feasible because it's a lot of work rhetoric... I would just like to hear
 the thoughts of the true experts subscribed to these lists :)

 No harm in that is there?

 Aras Russ Memisyazici
 Systems Administrator
 Virginia Tech

Re: Re[2]: Regular Expression Denial of Service

[Jeffrey Walton]

Hi Thierry,

 With all due respect - this is known to be a vulnerability
 class since over  a  century.
The referenced web page is titled, ReDoS (Regular Expression Denial
of Service) Revisited. The authors cite work as early as 2003 in
their paper.

 Can we please stop the  attitude of inventing
 acronyms for vulnerabilites, ...
Having a bad day?

 It's  the  impact  of  something  that makes it a vulnerability
 no the name.
In my humble opinion, the novelty is that Checkermax, a firm which
specializes in source code analysis, may be staging a tool to help
solve or alleviate the problem. At minimum, the firm has added to the
body of knowledge.

If you've ever had the pleasure of working behind someone who thinks
KR terseness is cool, you will welcome any and all tools to perform
static and dynamic analysis. These folks live in a fantasy world where
function calls do not fail and bad guys do not exist.

Jeff

On Fri, Sep 11, 2009 at 1:06 PM, Thierry Zoller thie...@zoller.lu wrote:
 Hi ,

 With all due respect - this is known to be a vulnerability class since
 over  a  century.  Just  because  it  doesn't  have a acronym à la XSS
 doesn't mean it's not known to be a vulnerability. Can we please stop
 the  attitude of inventing acronyms for vulnerabilites, making it look
 like it's something new and funky.

 It's  the  impact  of  something  that makes it a vulnerability no the
 name.


 GE Alex Roichman wrote:
 Checkmarx Research Lab presents a new attack vector on Web applications. By
 exploiting the Regular Expression Denial of Service (ReDoS) vulnerability an
 attacker can make a Web application unavailable to its intended users. ReDoS
 is commonly known as a “bug” in systems, but Alex Roichman and Adar Weidman
 from Checkmarx show how serious it is and how using this technique, various
 applications can be “ReDoSed”. These include, among others, Server-side of
 Web applications and Client-side Browsers. The art of attacking the Web by
 ReDoS is by finding inputs which cannot be matched by Regexes and on these
 Regexes a Regex-based Web systems get stuck.

 For further reading:
 http://www.checkmarx.com/NewsDetails.aspx?id=23cat=3

 GE Alex, nice work. Thank you for sharing it with us.

 GE I'd recommend taking a look at Ilja van Sprundel's work with regular
 GE expression bugs in his Unusual bugs presentation.
 GE ... Where he played a bit with Google Code Search back in 2007, I think.
 GE He helped Google out by giving them his research, of course.

 GE I found two versions online:
 GE http://www.ruxcon.org.au/files/2006/unusual_bugs.pdf
 GE http://www.slideshare.net/amiable_indian/unusual-bugs

 GE Ilja and I later discussed creating a real regex fuzzer to discover
 GE vulnerabilities, but I at least never had the time to play with it. He
 GE might have, I am CC:ing him.

 GE My best to Adar,

 GE Gadi Evron,
 GE http://www.gadievron.com/



 --
 http://blog.zoller.lu
 Thierry Zoller

Re: Norman Internet Update Deamon sends cleartext license key on update

[Jeffrey Walton]

Hi Stefan,

 linux norman internet update deamon (niu) sends our
 corporate license key in cleartext over http when the
 first update is triggered.
Similar problems (use of insecure channels) was reported on June 9,
2009 with their  Windows software.

Jeff

On Tue, Sep 1, 2009 at 3:00 AM, Stefan Bauerstefan.ba...@cubewerk.de wrote:
 I just discovered, that the linux norman internet update deamon
 (niu) sends our corporate license key in cleartext over http when
 the first update is triggered. Output of niu --trace shows

 SelectNextValServer (1): first: 0
 ExtractValServer: 0 from 'niuone.norman.no': Found 'niuone.norman.no'
 sAuthUrl='niuone.norman.no/scripts/NIUSrv.dll?GetUpdateInfo?1$asdfa-asdfa-asdfa-

               asdfa-asdfa$20022050205220702072208020822$5'(117)

 asdfa-asdfa-asdfa-asdfa-asdfa is our key.

 Norman confirmed the bug but did not provide a timeline for any updates.

 Regards

 --
 cubewerk -- stefan.ba...@cubewerk.de
 IT-Beratung + Planung --- Tel +49 8621 996 02 37
 Herzog-Otto-Straße 32 --- Fax +49 7211 513 38551
 83308 Trostberg  www.cubewerk.de

Fwd: Follow-up: Heartland CEO on Data Breach: QSAs Let Us Down

[Jeffrey Walton]

From the folks at Attrition and the DatalossDB.

-- Forwarded message --
From: security curmudgeon jeri...@attrition.org
Date: Aug 12, 2009 4:22 PM
Subject: Follow-up: Heartland CEO on Data Breach: QSAs Let Us Down
To: dataloss-disc...@datalossdb.org, datal...@datalossdb.org

http://www.csoonline.com/article/499527/Heartland_CEO_on_Data_Breach_QSAs_Let_Us_Down

Heartland CEO on Data Breach: QSAs Let Us Down

Heartland Payment Systems Inc. CEO Robert Carr opens up about his company's
data security breach, how compliance auditors failed to flag key attack vectors
and what the big lessons are for other companies.

By Bill Brenner, Senior Editor

August 12, 2009  CSO

For Heartland Payment Systems Inc. CEO Robert Carr, the year did not start off
well, to say the least.

In January, the Princeton, N.J.-based provider of credit and debit processing,
payment and check management services was forced to acknowledge it had been the
target of a data breach -- in hindsight, possibly the largest to date with 100
million credit and debit cards exposed to fraud.

In the following QA, Carr opens up about his company's data security breach.
He explains how, in his opinion, PCI compliance auditors failed the company,
how informing customers of the breach before the media had a chance to was the
best response, and how other companies can avoid the pain Heartland has
experienced.

[..]

Re: Re: Back door trojan in acajoom-3.2.6 for joomla

[Jeffrey Walton]

 ... or the developers were stupid enough to develop with old code.
Stupid may be a bit harsh. I find 'Software Security' is also a frame
of mind that *must* be backed by education. Perhaps the developers
lack the knowledge they need to model the threats and incorporate a
secure architecture.

Jeff

- Hide quoted text -

On 7/23/09, chris.boergerm...@wawerko.de chris.boergerm...@wawerko.de wrote:
 An early release of 4.0.0 has the same problem!

 So Acajoom has a general security issue or the developers
 were stupid enough to develop with old code.