| New User, Welcome! Login |
Next Page >>
saying
> I could only imagine. The other problem is that many people seem to think I'm saying something against
> the Chinese *people* themselves, based on the "f* you round-eye* messages I've received (and they call
> ME racist). They don't seem to get the clear distinction (to me) between the Chinese people and China's
> network. It's the machines I'm concerned with the attacks coming from those machine. Just because the
> machine is sourced in China doesn't mean the attacker is - so I have to do the best I can to defend against
> the machines. However, that unfortunately comes across to those who choose not to think it through as me
> saying something against the Chinese themselves.
> Then again, as you well know, people will take any opportunity they can just to be ugly and confrontational,
> and to have something to rail about. In the face of the reality of China's horribly infected network, when I
1. XSS 1
A HTTP GET request against the following URL will, on a web browser
with Javascript support, cause a dialog box saying '1' to be displayed:
http://CACTIHOST/graph.php?action=zoom&local_graph_id=1&graph_end=1%27%20style=visibility:hidden%3E%3Cscript%3Ealert(1)%3C/script%3E%3Cx%20y=%27
This vulnerability is only exploitable if the victim is allowed to view
graphs. This will be true if the victim has previously authenticated
contract from under Airbus' feet. In 1996, the CIA hacked into the computers of the
Japanese Trade Ministry seeking "negotiations on import quotas for US cars on the
Japanese market". Resulting with the information being passed off to "US negotiator
Mickey Kantor" who accepted a lower offer.
As an American you might say "so what, more power to us" but to think that any
government wouldn't do it to its own citizens for whatever reason would be absurd.
There are a lot of horrible routes this could take.
What happens if slash when for some reason or another the government decides that you
should not read a news site, will Microsoft willingly oblige and rewrite the news in
> cars on the
> Japanese market". Resulting with the information being passed off to
> "US negotiator
> Mickey Kantor" who accepted a lower offer.
>
> As an American you might say "so what, more power to us" but to think
> that any
> government wouldn't do it to its own citizens for whatever reason would
> be absurd.
> There are a lot of horrible routes this could take.
>
> If so, the cost of security by blocking may be unjustifiable.
Absolutely - If possible, please read the article at:
http://www.securityfocus.com/infocus/1900/1
It's dated, but the concepts hold true. The entire implementation is based on research and analysis, and of course, business applicability. To be sure, I receive significant US-based attack traffic, but I can't block that for business reasons. Unfortunately, many people see "block China" and immediately say "oh, that's unrealistic and ineffective." This is not an Internet based suggestion - it is a simply a toolset one may use to implement country-by-country, protocol-by-protocol based access policy. It's the same thing we do now from a protocol standpoint, but this simply allows one to aggregate data by geographic location. I have no business need for traffic to/from China and many other countries (which I also block) so even in the absence of hard attack traffic, "least privilege" dictates that it is valid to disallow traffic from sources that are not needed.
>
> 2. Urgency
>
> If so, the cost of security by blocking may be unjustifiable.
Absolutely - If possible, please read the article at:
http://www.securityfocus.com/infocus/1900/1
It's dated, but the concepts hold true. The entire implementation is based on research and analysis, and of course, business applicability. To be sure, I receive significant US-based attack traffic, but I can't block that for business reasons. Unfortunately, many people see "block China" and immediately say "oh, that's unrealistic and ineffective." This is not an Internet based suggestion - it is a simply a toolset one may use to implement country-by-country, protocol-by-protocol based access policy. It's the same thing we do now from a protocol standpoint, but this simply allows one to aggregate data by geographic location. I have no business need for traffic to/from China and many other countries (which I also block) so even in the absence of hard attack traffic, "least privilege" dictates that it is valid to disallow traffic from sources that are not needed.
>
> 2. Urgency
>
http://www.toribash.com
Versions: <= 2.71
Platforms: Windows, Mac and Linux
Bugs: A] dedicated server format string
B] client commands buffer-overflow
C] client unicode buffer-overflow in the SAY command
D] server crash through uninitialized values
E] line-feed dropping
F] Windows dedicated server hell bell
G] clients kicked by malformed packet
Exploitation: A, D and F versus server
"Update your anti-virus every 8 hours"
"Use a firewall in front of your network"
"Lick the USB connector before inserting it"
Oh, and compliance is a collection of these best practices. Do what
everyone else says to do or be punished by your peers! Yay for the
capitalistic, democratic legal system! Less for more!
3. Can you tell how many flies are in your home by the number of dead
ones on your front doorstep? If not then you're using the wrong
On 1/15/10 6:40 PM, Thor (Hammer of God) wrote:
> I could only imagine. The other problem is that many people seem to think I'm saying something against the Chinese *people* themselves, based on the "f* you round-eye* messages I've received (and they call ME racist). They don't seem to get the clear distinction (to me) between the Chinese people and China's network. It's the machines I'm concerned with the attacks coming from those machine. Just because the machine is sourced in China doesn't mean the attacker is - so I have to do the best I can to defend against the machines. However, that unfortunately comes across to those who choose not to think it through as me saying something against the Chinese themselves.
>
> Then again, as you well know, people will take any opportunity they can just to be ugly and confrontational, and to have something to rail about. In the face of the reality of China's horribly infected network, when I suggest blocking that traffic (as many others have and do), they seize the opportunity to call me prejudice and a racist.
The Chinese network is indeed very infected, which in turn causes the
rest of the world great computerized harm. Nobody disputes this.
The solution of blocking China, however, is one which harms both people
outside of China, as well as those inside of China. Therefore, it
On Thu, 1 Nov 2007, Thor (Hammer of God) wrote:
> But more importantly, let's look at things from the other side. Let's
> say I'm wrong, and that Gadi is right on target with his "hit hard"
I'd say we are both right.
You look at it from a security researcher stand-point. There is nothing
interesting about user-interaction, and it is even kind of lame.
From a reasonable perspective, we refuse to believe people will act so ..
silly.
On Thu, 23 Aug 2007, M. Burnett wrote:
> You are correct that this isn't an issue for everyone and you are correct
> that this isn't an issue if reasonable security practices are employed. On
> the other hand, most security issues reported here wouldn't be issues if
> reasonable security practices were employed. I have been saying that for
> years.
Amen.
> Because it does not apply to your particular environment doesn't invalidate
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 <nowhere@devnull.com>:
> :)
>
> Thank you all for your valuable comments... Indeed I appreciated some of the
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: Susan Bradley [mailto:sbradcpa@pacbell.net]
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
>
>> 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
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
>>>>
>>> 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
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
>
Hello Thierry!
> Your saying above that this attack works if "Initialise and script
> ActiveX control not marked as safe" is ENABLED.
This Saved XSS hole works even with this option disabled (i.e. with default
settings). But when we want to use ActiveX in our code (e.g. for Code
Execution attack), than such problem occurs. It's bug in IE (when there is
preceding comment tag), which I found when researching possibility of making
CE via XSS in IE. So I found the workaround for this bug - to set up this
> Let's not over-hype this-- while "Apple's day" has been coming, saying
that users will be "hit hard" on something the user has to
> manually download, manually execute, and explicitly grant
administrative privileges to is *way* over the top.
The future of malware is going to be largely through social engineering.
Does that mean we ignore every threat that comes out because it requires
user interaction? Seems like whistling past the graveyard to me.
Alex
HvyAAKhouMDUKBe0VHAabMM=
=GzY/
-----END PGP SIGNATURE-----
On 11/1/07, Alex Eckelberry <AlexE@sunbelt-software.com> wrote:
> > Let's not over-hype this-- while "Apple's day" has been coming, saying
> that users will be "hit hard" on something the user has to
> > manually download, manually execute, and explicitly grant
> administrative privileges to is *way* over the top.
>
> The future of malware is going to be largely through social engineering.
>
>
> On Nov 1, 2007 9:49 PM, Alex Eckelberry < AlexE@sunbelt-software.com> wrote:
>
> >
> > > Let's not over-hype this-- while "Apple's day" has been coming, saying
> > that users will be "hit hard" on something the user has to
> > > manually download, manually execute, and explicitly grant
> > administrative privileges to is *way* over the top.
> >
> > The future of malware is going to be largely through social engineering.
My guess (and I'd really like to see details on your findings) is that
most "interactive" issues are the more "trivial" interactive issues
(like clicking a link and launching a vulnerable version of IE).
But more importantly, let's look at things from the other side. Let's
say I'm wrong, and that Gadi is right on target with his "hit hard"
prediction and that we should be very concerned with this. Given the
requirements here, that again being flagrant ignorance where all the
above steps are executed (including the explicit admin part)-- what
exactly are we supposed to do? If people are willing and able to go
through the motions above what can we as security people do to prevent
My guess (and I'd really like to see details on your findings) is that
most "interactive" issues are the more "trivial" interactive issues
(like clicking a link and launching a vulnerable version of IE).
But more importantly, let's look at things from the other side. Let's
say I'm wrong, and that Gadi is right on target with his "hit hard"
prediction and that we should be very concerned with this. Given the
requirements here, that again being flagrant ignorance where all the
above steps are executed (including the explicit admin part)-- what
exactly are we supposed to do? If people are willing and able to go
through the motions above what can we as security people do to prevent
email a target, and not only get them to open your attachment (against
warnings), but to then click "connect," and finally, to actually enter
their username and password into your host (where you still have to get
them, btw). *SO* much more has to happen beyond the "tool" that it
doesn't matter. Besides, I don't think users know anything about .rdp
files -- I can say that I've never, ever, been emailed an rdp file.
> And how come it is OK for a simple text file be able to ride your
> session and execute commands on behalf of you? I think that this is a
> problem. CSRF is a well known, widely acknowledged problem. The client
> should at least warn you that you are about to start an alternative
> email a target, and not only get them to open your attachment (against
> warnings), but to then click "connect," and finally, to actually enter
> their username and password into your host (where you still have to get
> them, btw). *SO* much more has to happen beyond the "tool" that it
> doesn't matter. Besides, I don't think users know anything about .rdp
> files -- I can say that I've never, ever, been emailed an rdp file.
>
> > And how come it is OK for a simple text file be able to ride your
> > session and execute commands on behalf of you? I think that this is a
> > problem. CSRF is a well known, widely acknowledged problem. The client
> > should at least warn you that you are about to start an alternative
forethought and intelligence.
I've said this once already, but it bears repeating: your concerns deserve
discussion in context of vmware best practices. But I personally don't
believe it merits discussion as a vulnerability. It's no more a
vulberability than, say, not setting a password on your Windows
administrator account. It's obviously idiotic, but not a flaw in the
software stack.
> I think some of you are overanalyzing this issue. I am well aware that there
> are other ways to accomplish the same thing in many instances, I am not
>> "c:\Program Files\Symantec\Symantec Endpoint Protection\symcorpui.exe"
>>
>>
>>
>> If you have NTP installed, It would not be there and if you only have the
>> NTP installed, It will say "No Problems detected- No protection
>> technology is installed" and nothing in that board. If you go to help and
>> support > Troubleshooting. The server is offline for the client.
>>
>>
>>
"c:\Program Files\Symantec\Symantec Endpoint Protection\symcorpui.exe"
If you have NTP installed, It would not be there and if you only have the
NTP installed, It will say "No Problems detected- No protection technology
is installed" and nothing in that board. If you go to help and support >
Troubleshooting. The server is offline for the client.
> problem but an actual problem.
>
>
> Sorry Ben, but any web site or service (HTTP, SMPT, IMAP, SSH, VPN, etc)
> which makes use of a compromised key has an actual problem and not a
> potential problem. Open ID as a standard isn't more affected than, lets say
> XMPP...If there are servers and providers relying on such keys the have a
> real actual problem.
I do not dispute this.
Next Page>>
|
|
|
