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.
...

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: 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=svn545&r=545).

On Mon, Mar 25, 2013 at 10:00 PM,   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:
> ...

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  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: Facebook Information Disclosure

[Jeffrey Walton]

On Fri, Jun 21, 2013 at 5:40 PM, Packet Storm
 wrote:
> Worth Reading:
>
> http://packetstormsecurity.com/news/view/22713/Facebook-Where-Your-Friends-Are-Your-Worst-Enemies.html
>
> https://www.facebook.com/notes/facebook-security/important-message-from-facebooks-white-hat-program/10151437074840766
Great write-up.

>From the write-up:

]] It was clear that Facebook attacked the disclosure flaw properly, but
]] concerns still remain about the fact that dossiers are being built on
]] everyone possible. We had to ask hard questions. The fact that I
]] have no control over additional email addresses and phone numbers
]] added to their data store on me is frightening. The questions we
]] asked were very to the point but carefully constructed to reflect an
]] equal balance between usability and user safety. After all, my
]] personal safety is paramount at Facebook right?
If you don’t want your data analyzed, inspected, shared, mishandled,
lost or stolen, then don’t provide to social networking experiments,
clouds and drop boxes in the first place.

Jeff

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

[Jeffrey Walton]

On Fri, Jul 12, 2013 at 2:16 PM,   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(n<0)
> 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

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
 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: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[Jeffrey Walton]

On Sat, Aug 10, 2013 at 6:10 AM, Gichuki John Chuksjonia
 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] Apache suEXEC privilege elevation / information disclosure

[Jeffrey Walton]

On Mon, Aug 12, 2013 at 1:28 PM, Coderaptor  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  wrote:
>
>> Am 11.08.2013 23:56, schrieb Stefan Kanthak:
>>> "Reindl Harald"  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] 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  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:
>
> *  alias
>   
>
> * 
>
> * 
>
> *  alias
>   
>
> *  alias
>   
>
> * 
>
> *  alias
>    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 
> 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%
> 

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 R

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

[Jeffrey Walton]

> 2014-06-03 16:16 GMT+02:00 Hector Marco :
>
> 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

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.
...

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).

Re: [Full-disclosure] pidgin OTR information leakage

[Jeffrey Walton]

On Mon, Feb 27, 2012 at 3:21 PM, Rich Pieri  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

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

[Jeffrey Walton]

Interesting reading from the cryptography mailing list

-- Forwarded message --
From: David I. Emery 
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] [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
 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

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 :   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
 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
 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: Perfect PDF products distributed with vulnerable MSVC++ libraries

[Jeffrey Walton]

On Tue, Jun 21, 2011 at 7:22 AM, Brad Hards  wrote:
> On Sunday 19 June 2011 11:37:33 Stefan Kanthak wrote:
>> soft Xpansion  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
>> 
>> and
>> 
> 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

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: Vulnerabilities in trading and SCADA softwares

[Jeffrey Walton]

On Wed, Sep 14, 2011 at 5:13 AM,   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

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

[Jeffrey Walton]

On Thu, Sep 15, 2011 at 7:11 PM, Michael Schmidt  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 
> 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)
>>  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
>>   

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: OpenBSD CARP Hash Vulnerability

[Jeffrey Walton]

On Fri, Dec 17, 2010 at 10:08 PM, Sam Banks  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]

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  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.
>

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 
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 Q&A, 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: 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 Bauer 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
>

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
K&R 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  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=23&cat=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: 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
 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 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  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
>>  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
>>>
>>>
>>>
>>
>>
>
>