Next Page >>
don't think
Well, YES... The "collums" showing the exploit structure should
address this misunderstood. Anyway, here is a question: What happens
if we apply Alpha2.c, or any other polymorphic shellcode engine, to
the entiry data we should write in the stack? Will the exploit work? I
don't think so. Touche!!!
>> That is the reason some
>> IPS/IDS can easily add signatures.
> Well, actually shellcode signatures are common, but they are not the reason.
So, you guys don't think it's an issue that power management in Vista
(apparently) has a pass to bypass local security policy?
--
Abe Getchell
me@abegetchell.com
https://abegetchell.com/
> -----Original Message-----
> From: Thor (Hammer of God) [mailto:thor@hammerofgod.com]
Sent: Sunday, July 20, 2008 12:32 PM
To: 'Thor (Hammer of God)'; Jim Harrison; 'Johan Beisser'
Cc: bugtraq@securityfocus.com
Subject: RE: Windows Vista Power Management & Local Security Policy
So, you guys don't think it's an issue that power management in Vista
(apparently) has a pass to bypass local security policy?
--
Abe Getchell
me@abegetchell.com
> > an exploit for IE right now and they don't patch it until April September
> > 2008, it's a 0day exploit for a year. It's not necessarily new and it
> > doesn't have to be used maliciously.
> >
> > If I code an exploit (for which there is no patch) and use it on my own
> > servers, does that mean it's not 0day? I don't think so. If my WordPress
> > blog gets owned by pwnpress, that's not 0day.. there's patches/updates for
> > everything on there. It just makes me an idiot for not upgrading. Now if
> > I get hit with some WP exploit that's not patched, then that's another
> > [0-day] story.
> >
Bye bye my little 0day :(, Tavis Ormandy did a great job uncovering a
big logic flaw within Java JRE. I discovered that bug and other that
affects every browser few weeks ago and I posted the common "0day++" tweet.
The method in which Java Web Start support has been added to the JRE is
not less than a deliberately embedded backdoor(I really don't think so)
or a flagrant case of extreme negligence (+1).
It's even more incredible that Sun didn't assess the real risk of this
flaw after Tavis reported it to them.
Let's see:
signal ratio and making this law that much less effective, while placing
a greater burden of ISPs who are then more likely to lobby against it
ever more vigorously.... all while remaining entirely 'white area' in
terms of functionality.
I understand your post, but I don't think Mr. Ziegler was over-selling
his product's effectiveness beyond what it is really capable of.
Take care, Matt
johan beisser wrote:
I would agree that this isn't a particularly high-severity bug. On one
hand, it can be triggered reliably; on the other hand, it requires
local access and probably can't achieve more than DoS.
Even so, the restrictions on the sending of signals are considered a
security mechanism, so I don't think that it's unreasonable to
consider this a security issue regardless of the extent to which
existing setuid binaries are affected by it.
AFAICT, the intent was that PDEATHSIG would be subject to the same
kind of restrictions as kill() or F_SETOWN etc. But in this case, the
>
> > IOW, I really don't think the tag had that much to do with it now...
>
> People are just picking on you because they can. I can only share how I
> see such Internet discussions.
>
> Cost of doing business, just consider your responses on a level of
proc_fd_info() called from proc_fd_link() obtains file->f_path, that in turn
contains the reference to the open file dentry and hence inode. That's exactly
why those symlinks behave as hardlinks. This behavior assumes, that if you were
able to open the file, you've all necessary transition permissions to access
it's inode. But in order to follow them you need privileges to read the process
memory, which hardly restricts the impact of this behavior. I don't think this
should be fixed, since /proc/<PID>/fd/ is mainly for debugging purposes.
--
Sincerely Your, Dan.
As stated in my original e-mail to the list, I definitely don't think that
this is a security vulnerability in a traditional sense. I completely agree
with you. Think about it this way... When you press the power button on the
machine and it performs a graceful shutdown, stuff happens inside of the
operating system. That stuff happens at an elevated privilege level. If
there were some way to hook into the stuff that happens, you (as an
unauthenticated user), could do bad things (besides simply shutting down the
system) using that hook simply by pressing the power button at the logon
screen. For example, if Jim wants to know what Nancy is working on, he could
write a program which e-mails him the contents of her "My Documents" folder
Aside to that, I know some people in China who work very hard on
security, and do a better job than we do at it. But that does not mean
the situation as it stands now is acceptable.
> IOW, I really don't think the tag had that much to do with it now...
People are just picking on you because they can. I can only share how I
see such Internet discussions.
Cost of doing business, just consider your responses on a level of (time
learning about a vulnerability for which there is a working exploit, and no
way to protect yourself short of impacting the availability of your systems
by unplugging them or disabling the affected service."?
I'd propose "unpatched vulnerability with known working exploit", but it's
kind of verbose, and I don't think some of the kids joining our ranks can
string that many complete words together anymore (too much texting).
Terry
#include <stddisclaim.h>
> learning about a vulnerability for which there is a working exploit, and no
> way to protect yourself short of impacting the availability of your systems
> by unplugging them or disabling the affected service."?
>
> I'd propose "unpatched vulnerability with known working exploit", but it's
> kind of verbose, and I don't think some of the kids joining our ranks can
> string that many complete words together anymore (too much texting).
UV:WE
Unpatched Vulnerability: Working Exploit
violates this expectation.
It is obscure, because it requires User1 to go through an unusual sequence
of steps, but not inconceivable.
|| I don't think what Pavel described is a very serious hole, but it *IS*
|| a hole, because:
||
|| 1. It circumvents the fact that to write to a file, you MUST be able
|| to write to its directory, so that the file attributes can be updated.
|| That's an important part of accountability.
(both using mirc 6.3)
similar behavior as clicking start -> run and pasting the URI
regardless, unless you can pass arbitrary arguements or pass data on
to a server, i don't think you're going to find many already existing
executables on the user's system to do malicious tasks with this "mirc
bug". various tests can't even get notepad to open a simple txt file.
you can't even run shutdown.exe without specifying some arguments.
research kills frivolous 0day announcements.
> Note that if they had been served with an NSL (National Security Letter),
> they may be legally *required* to lie about it while cooperating. Actually
> truthfully saying "Yeah, an NSL showed up and we complied" could land them
> in jail....
I don't think that they are required to actively lie about it.
There is a difference between:
Q: Have you been served with an NSL?
A: No.
by sending them a similar (fake)-contract/NDA, asking them not to use
OpenSSH, but share National Sensitive information. In other words, just
ask them to share THEIR knowledge without US providing our tools.
There are some times where I hate the BSD licence, because it does not
force people to cooperate! (even if I don't think any other licence
would help here...)
My 2 cents and sorry for the off-topic subject...
Cheers
> by sending them a similar (fake)-contract/NDA, asking them not to use
> OpenSSH, but share National Sensitive information. In other words, just
> ask them to share THEIR knowledge without US providing our tools.
>
> There are some times where I hate the BSD licence, because it does not
> force people to cooperate! (even if I don't think any other licence
> would help here...)
>
> My 2 cents and sorry for the off-topic subject...
>
> Cheers
Dear Geo,
Thank you for the challenge, Geo. Your trying to get the discussion in
a direction that doesn't serve the purpose of the finding, nor would
it "proof" anything. I welcome your task though I'd like you to know
that I don't think I have to proof anything to you. However if you pay
enough I might invest some time ;)
Again Geo, NOBODY has said that this is a vulnerability OF IE7 ITSELF we said
the handler that IE7 installs is broken. I honestly think we have
discussed the problem itself enough, it's up to Microsoft now to
doesn't address these issues or even concded that there's necessarily
anything they can do about it. They instead speak of the same
precautions for physical access that they spoke of a couple weeks ago
with respect to the "frozen notebook memory" attack - use drive
encryption, use 2-factor authentication, use hibernate instead of sleep,
use group policy to enforce them. I don't think it's a bad response
under the circumstances. The fact that you can turn off DMA on Linux
seems in fact inferior to simply disabling the Firewire port and driver
at run-time in Windows. They both suck as solutions.
Incidentally, Microsoft made a few other points in their response that
> doesn't address these issues or even concded that there's necessarily
> anything they can do about it. They instead speak of the same
> precautions for physical access that they spoke of a couple weeks ago
> with respect to the "frozen notebook memory" attack - use drive
> encryption, use 2-factor authentication, use hibernate instead of sleep,
> use group policy to enforce them. I don't think it's a bad response
> under the circumstances.
WRT the DMA access over FireWire it's but a bad response since it doesn't
get the point!
======
4) Fix
======
The developers don't think this can be considered a security problem
while in my opinion doing something outside the environment created by
the virtual machine must be considered a risk.
#######################################################################
>Windows Vista fully updated is not affected.
>I think it's a problem in your Antivirus and NOT in Windows
I don't think so - several users confirmed the issue (including Vista). The only differences are the amount of CPU taken (sometimes 50%, sometimes 100% - probably dual-core issues)
Did you try to click on the png file one more time, and check the CPU usage ?
http://archives.neohapsis.com/archives/fulldisclosure/2009-12/0415.html
by another author.
I have not checked other offshoots.
I am writing because I don't think the original full disclosure email
provided sufficient information as to how this could be typically
exploited in a system with typical installations of SQL-Ledger or
offshoots. Indeed, when combined with standard functionality of the
software in typical configurations, the vulnerability is relatively
easy to exploit and does not require external upload access.
give Fox News style comments ?
FFL> the title is misleading at best.
While I have the upmost respect of your person, in this particular
case, I am sorry dude, but how can you tell ? Have you seen the
presentation? Have you heard the conclusion? I don't think so?
Though you are more than welcome to see it :)
FFL> Defense in Depth has nothing to do
FFL> with security software.
In a certain sense it has. Defence in depth is a Paradigm as not only
http://weblog.infoworld.com/securityadviser/archives/WindowsExploitAnaly
sis.xls
It's not perfect, and may even contain a few mistakes. However, I don't
think any of the mistakes would change the overall numbers much. The
exploit chart (I listed two years of vulnerabilities, not three as I
mistakenly said earlier) lists publicly disclosed Windows
vulnerabilities by CVE number and MS number (where it exists). I did
not care about whether it was trivial to exploit or hard to exploit.
Per a report the Microsoft Security Response Center (MSRC) released
Well, as James pointed out already, this reply is a little silly.
But, just to be clear, if Mitsubishi had explicitly documented that this
device should only be used on a private network and had no access
controls, I don't think I'd have a problem.
However, they show a username/password box (which I'm betting is fairly
easilly circumvented if you know the right urls and can forge a cookie
on the client...) so I think it's fair game to expect them to implement
some kind of real security.
back to IP resources located in the North Pole and controlled by one
"Kr1S Kr1gL3" who has apparently privately purchased access rights to
all Hushmail data in an effort to determine which users have been
"naughty" and which have been "nice."
Coincidence? I don't think so.
t
A longer explanation:
The main problem is that if users have filesystem access to the mail
server, they can create symlinks. Dovecot doesn't try to prevent
following symlinks (and I don't think it should) and normally it isn't a
problem. But when mail_extra_groups=mail is set:
1a) Maildir: Any files readable by mail group can be read by the user by
symlinking the file to their ~/Maildir/cur/.
the DMA controller to redirect certain memory accesses. I do not
believe this has been turned into anything like a usable tested patch
for any major operating system to defend it's privileged kernel memory,
and unless API's were created to designate the need for 'secured' memory
storage for things like passwords to be stored in these areas that the
DMA controller directed away from... I don't think this is yet a viable
solution. I think it is the beginning of an idea for one though.
Did you have something else in mind? If so, what is holding back
implementation?
Next Page>>
|
