Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

On 25.01.2012 08:44, Peter Osterberg wrote: > I don't think that is what Ben is saying. The clipboard get sent to the > the server even before it is pasted, this happens without the user > knowing of it. > > Notepad would have the paste button grayed otherwise, if the clipboard > is empty, right? S

Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

On 25.01.2012 00:52, Henri Salo wrote: > On Wed, Jan 25, 2012 at 12:47:28AM +0100, Ben Bucksch wrote: >> On 25.01.2012 00:09, Dan Kaminsky wrote: >>> IP KVM, in which the foreign server basically gets only inbound >>> Keyboard and Mouse and outbound uncompressed pixels.

Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

On 25.01.2012 00:09, Dan Kaminsky wrote: > IP KVM, in which the foreign server basically gets only inbound > Keyboard and Mouse and outbound uncompressed pixels. That is *precisely* what VNC is: an open-source IP KVM. And please don't turn this into "you're stupid", because I've seen others wit

Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

On 24.01.2012 20:08, Giles Coochey wrote: > I have seen this is an often requested feature Yes, I understand. It can be highly useful. That's why I proposed to make a "Paste" button in the main toolbar (probably with a keyboard shortcut, too). So, the user would have to press one more button / k

Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

On 24.01.2012 19:18, Mario Vilas wrote: > You're reporting that if you copy and paste sensitive information and > connect to a VNC session your clipboard data gets sent to the remote > machine. That's pretty obvious If I have a VNC window somewhere on my desktop (in my case a virtual desktop or m

Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

On 24.01.2012 18:07, Mario Vilas wrote: > Expected result is to have the clipboard text sent to the remote > machine, if you have your client configured to do so But I haven't done so. That's the bug. > security sensitive environment you wouldn't be using the clipboard for > passwords anyway. An

Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

On 24.01.2012 16:32, Giles Coochey wrote: > Many viewers, including RealVNC have the option to disable the shared > clipboard. Check your preferences. Indeed. But Vinagre doesn't. Even then, that is not sufficient, as explained in length. ___ Full-Disc

[Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

Affected Products: GNOME Vinagre and many other VNC viewers Reproduction: 1. On your trusted desktop (e.g. Linux), open a text editor 2. Type "My password", select the text, and hit Ctrl-C 3. Open a Vinagre VNC connection to a remote host, e.g. running an untrusted Windows 4. On the remote Window

Re: [Full-disclosure] Stealing Browser History Without Using JavaScript

See https://bugzilla.mozilla.org/show_bug.cgi?id=14 Using CSS :visited with CSS background-image is a nice idea (not sure whether new, would need to read the bug). Note that this is not an implementation but, but a problem in the CSS spec. RSnake wrote: > In case anyone is interested,

Re: [Full-disclosure] Firefox Cache Hack - Firefox History Hack redux

pdp (architect) wrote: > it tells you which URLs you have attended during the current browser > session Filed bug It seems you can only test for specific URLs, not really getting the list. See also bug

Re: [Full-disclosure] phishing sites examples "source code"

Andres Riancho wrote: > For a research i'm doing I need a somehow "big"(around 100 would > be nice...) amount of phishing sites html code . I have googled for > them but I only get a lot of screenshots of those sites, not the > actual code. Anyone has an idea of where I could get those sites

Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability

https://bugzilla.mozilla.org/show_bug.cgi?id=370445 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)

Michal Zalewski wrote: > And it's not really that much of an issue: disallow script-assisted > focusing on file input fields, or a) prevent event target from being > changed in onKeyDown (this is what MSIE does) + b) prevent scripts from > reading file input field value (really no reason for them t

Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)

pdp (architect) wrote: > try this > > > > setInterval(function () { > document.getElementById('foo').focus(); > },1); > > > :) the address bar is disabled... Funny. Filed as bug 370094 ___ Full-D

Re: [Full-disclosure] Firefox focus stealing vulnerability (possibly other browsers)

Thanks for the report, Michal. Filed as bug 370092 BTW: Your last bug (popup blocker + XMLHttpRequest + srand() = oops) was filed as bug 369390 The factors of the bug are filed as separate

Re: [Full-disclosure] Firefox + popup blocker + XMLHttpRequest + srand() = oops

No, we never patch bugs. Where would this lead us? Only commies taking over! Tracked in bug 369390. James Matthews wrote: > Do you think it will be patched?? > > On 2/5/07, *Michal Zalewski* <[EMAIL PROTECTED] > > wrote: > > On Mon, 5 Feb 2007, pdp (architect) wrote

Re: [Full-disclosure] JavaScript inLine Debugger - The fastest web sites debugger (technique, not a tool)

SirDarckCat wrote: > JaSiLDBG > JavaScript inLine Debugger Are you selling us the "javascript:" URL as "JaSiLDBG JavaScript inLine Debugger"? From all I can tell from your doc, you simply renamed "javascript:" to "JaSiLDBG". Would have been more appropriate, and more useful, if you would have

Re: [Full-disclosure] Seeking comment on disclosure articles

I hope you realize that you open a highly controversial subject, i.e flamewar. My current approach is: Basic idea is that vendors should have the ability to fix them without the public exploiting it at the same time, but even during the secret time, various parties will see the bug, so this tim

Re: [Full-disclosure] Perforce client: security hole by design

Anders B Jansson wrote: > I'd say that it's a design decition, not sure that it's a design flaw. > It's all down to what you try to protect. > ... connecting any device not 100% controlled by the company to a company > network is strictly forbidden, doing so would be regarded as intended > sabota

[Full-disclosure] Perforce client: security hole by design

ould reassure the security of the client vs. server would be to make the client source open for review (preferably as Open Source) and make the protocol available for everybody to implement their own clients. Ben Bucksch http://www.bucksch.org Emails please to [EMAIL PROTECTED], sorry for the inc