Re: [Full-disclosure] 3rd party patch for XP for MS09-048?

2009-09-17 Thread John Morrison
On http://support.microsoft.com/gp/lifepolicy MS says that the
Extended Support Phase includes Security Update Support. If I have
a Premier Support contract (which entitles me to Extended Support)
aren't MS contractually obliged to make this fix available to me?


2009/9/16 Aras Russ Memisyazici nowh...@devnull.com:
 :)

 Thank you all for your valuable comments... Indeed I appreciated some of the
 links/info extended (Susan, Thor and Tom) However, in the end, it sounded
 like:

 a) As a sysadmin in charge of maintaining XP systems along with a whole
 shebang of other mix setups, unless I deploy a better firewall solution, I
 seem to be SOL.

 b) M$ is trying to boost Win7 sales... whoopd...@#$%#^-doo... As was stated
 earlier, they did the exact same thing back in Win2K days... Nothing new
 here... :/ As Larry and Thor pointed out, what sux is that despite M$
 PROMISING that they would continue supporting XP since they didn't exactly
 state WHAT they would support, they seem to be legally free to actually get
 away with this BS *sigh* gotta love insurance-salesman-tactics when it comes
 to promises...

 So... with all this commentary, in the end, I still didn't read from the
 big'uns on whether or not a 3rd party open-source patch would be
 released... I sure miss the days that people back in the day who cared would
 :) In the end I realize, it sounds like a total over-haul of the TCP/IP
 stack is required; but does it really have to? Really?

 How effective is what Tom Grace suggests? Unless I'm misunderstanding, he's
 suggesting switching to an iptables based protection along with a registry
 tweak... ahh the good ol' batch firewall :) Would this actually work as a
 viable work-around? I realize M$ stated this as such, but given their
 current reputation it's really hard to take their word for anything these
 days :P

 What free/cheap client-level-IPS solutions block this current attack? Any
 suggestions?

 Thank you for your time and look forward to some more answers.

 Sincerely,
 Aras Russ Memisyazici
 arasm {at) vt ^dot^ edu  -- I set my return addy to /dev/null for... well
 you know why!

 Systems Administrator
 Virginia Tech

 -Original Message-
 From: Larry Seltzer [mailto:la...@larryseltzer.com]
 Sent: Wednesday, September 16, 2009 5:03 PM
 To: Susan Bradley; Thor (Hammer of God)
 Cc: full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com
 Subject: RE: [Full-disclosure] 3rd party patch for XP for MS09-048?

 Yes, they used the bulletin to soft-pedal the description, but at the
 same time I think they send a message about XP users being on shaky
 ground. Just because they've got 4+ years of Extended Support Period
 left doesn't mean they're going to get first-class treatment.

 Larry Seltzer
 Contributing Editor, PC Magazine
 larry_selt...@ziffdavis.com
 http://blogs.pcmag.com/securitywatch/


 -Original Message-
 From: full-disclosure-boun...@lists.grok.org.uk
 [mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Susan
 Bradley
 Sent: Wednesday, September 16, 2009 2:26 PM
 To: Thor (Hammer of God)
 Cc: full-disclos...@lists.grok.org.uk; bugtraq@securityfocus.com
 Subject: Re: [Full-disclosure] 3rd party patch for XP for MS09-048?

 It's only default for people running XP standalone/consumer that are
 not even in a home network settings.

 That kinda slices and dices that default down to a VERY narrow sub sub
 sub set of customer base.

 (Bottom line, yes, the marketing team definitely got a hold of that
 bulletin)

 Thor (Hammer of God) wrote:
 Yeah, I know what it is and what it's for ;)  That was just my subtle
 way of trying to make a point.  To be more explicit:

 1)  If you are publishing a vulnerability for which there is no patch,
 and for which you have no intention of making a patch for, don't tell me
 it's mitigated by ancient, unusable default firewall settings, and don't
 withhold explicit details.  Say THERE WILL BE NO PATCH, EVER.  HERE'S
 EVERYTHING WE KNOW SO YOU CAN DETERMINE YOUR OWN RISK.  Also, don't say
 'you can deploy firewall settings via group policy to mitigate exposure'
 when the firewall obviously must be accepting network connections to get
 the settings in the first place. If all it takes is any listening
 service, then you have issues.  It's like telling me that the solution
 is to take the letter 'f' out of the word solution.

 2)  Think things through.  If you are going to try to boot sales of
 Win7 to corporate customers by providing free XP VM technology and thus
 play up how important XP is and how many companies still depend upon it
 for business critical application compatibility, don't deploy that
 technology in an other-than-default configuration that is subject to a
 DoS exploit while downplaying the extent that the exploit may be
 leveraged by saying that a typical default configuration mitigates it
 while choosing not to ever patch it.    Seems like simple logic points
 to me.

 t


 -Original Message-
 From: 

Re: [reiserfs-list] major security bug in reiserfs (may affect SuSE Linux)

2001-01-09 Thread John Morrison

I can't reproduce this.

[root@vaio /root]# mkdir "$(perl -e 'print "x" x 768')"
[root@vaio /root]# ls











[root@vaio /root]#



John


 We are still investigating, but there seems to be a major security problem
 in at least some versions of reiserfs. Since reiserfs is shipped with
 newer versions of SuSE Linux and the problem is too easy to reproduce and
 VERY dangerous I think alerting people to this problem is in order.

 We have tested and verified this problem on a number of different systems
 and kernels 2.2.17/2.2.8 with reiserfs-3.5.28 and probably other versions.

 Basically, you do:

 mkdir "$(perl -e 'print "x" x 768')"

 I.e. create a very long directory. The name doesn't seem to be of
 relevance (we found this out by doing mkdir "$(cat /etc/hosts)" for other
 tests). This works.  The next ls (or echo *) command will segfault and the
 kernel oopses. all following accesses to the volume in question will oops
 and hang the process, even afetr a reboot.

 reiserfsck (the filesystem check program) does _NOT_ detect or solve this
 problem:

 Replaying journal..ok
 Checking S+tree..ok
 Comparing bitmaps..ok

 But fortunately, rmdir filename works and seems to leave the filesystem
 undamaged.

 Since a kernel oops results (see below), this indicates a buffer overrun
 (the kernel jumps to address 78787878, which is "") inside the kernel,
 which is of course very nasty (think ftp-upload!) and certainly gives you
 root access from anywhere, even from inside a chrooted environment. We
 didn't pursue this further.

 The best workaround at this time seems to be to uninstall reiserfs
 completely or not allow any user access (even indirect) to these volumes.
 While this individual bug might be easy to fix, we believe that other,
 similar bugs should be easy to find so reiserfs should not be trusted (it
 shouldn't be trusted to full user access for other reasons anyway, but it
 is still widely used).

 Unable to handle kernel paging request at virtual address 78787878
 current-tss.cr3 = 0d074000, %cr3 = 0d074000
 *pde = 
 Oops: 0002
 CPU:0
 EIP:0010:[c013f875]
 EFLAGS: 00010282
 eax:    ebx: bfffe78c   ecx:    edx: bfffe78c
 esi: ccbddd62   edi: 78787878   ebp: 0300   esp: ccbddd3c
 ds: 0018   es: 0018   ss: 0018
 Process bash (pid: 292, process nr: 54, stackpage=ccbdd000)
 Stack: c013f66a ccbddf6c cd10 ccbddd62 030c c0136d49 0700 2013
1000 7878030c 78787878 78787878 78787878 78787878 78787878 78787878
78787878 78787878 78787878 78787878 78787878 78787878 78787878 78787878
 Call Trace: [c013f66a] [c0136d49]
 Code: 89 1f 8b 44 24 18 29 47 08 31 c0 5b 5e 5f 5d 81 c4 2c 01 00