[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ 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] [Full-Disclosure] (Psexec on *NIX)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 02 February 2007 12:08, [EMAIL PROTECTED] wrote: On Fri, 02 Feb 2007 13:25:11 +0800, Eduardo Tongson said: On 2/2/07, Xavier Beaudouin [EMAIL PROTECTED] wrote: Allowing direct root login even with SSH is IMHO stupid... Please elaborate why is it IYHO stupid. In environments where more than 1 person has root access, allowing direct login to root means you can't keep an audit trail of which person logged in. And if your environment only one person has root access, that's just looking for a DoS if the one person is hit by a bus. I believe we have had this discussion before, but I'll iterate my beliefs in favour of allowing direct root access again: - - Key-based root logins are quite secure. I don't see any reason why key-based root login would be any less secure than permitting a user login followed by an sudo. - - Password management is a bitch. I don't remember passwords for about half the accounts I have. Using a key-based root login, I don't need to remember those passwords either. If you take the sudo route, every user has to remember each password for each account, unless you take the deprecated route of reusing passwords (or *horrors* allow sudo without password). - - With a little bit of configuration, it's easy to figure out which key was used to login to an account; the audit trail can be managed that way. - - Managing which users have access to which root accounts is trivial this way: just add or delete their keys from .ssh/authorized_keys[2]. Of course, ideally you could use a combination of user-based and key-based logins: allow users to login any which way they want, then only allow key-based root ssh from localhost. Hmm, that's an idea worth exploring... Regards, - -- Raju - -- Raj Mathur [EMAIL PROTECTED] http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F It is the mind that moves -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwvINyWjQ78xo0X8RAs9tAJ9fc7PXCY/ITlhWZdx0Pang0/mWMgCfcOkg eSmt2EEur8Jr3W9rodZEhn4= =DSri -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ 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] [Full-Disclosure] (Psexec on *NIX)
On Fri, 02 Feb 2007 13:40:47 +0530, Raj Mathur said: I believe we have had this discussion before, but I'll iterate my beliefs in favour of allowing direct root access again: - Key-based root logins are quite secure. I don't see any reason why key-based root login would be any less secure than permitting a user login followed by an sudo. It's not the security of the login itself - it's the ability to create an audit trail of which userid performed an action. If you can find some other way to... - With a little bit of configuration, it's easy to figure out which key was used to login to an account; the audit trail can be managed that way. ... like the above, then most of the issues can be worked around. The *problem* with direct login to root is that it's the very rare site that actually manages to implement it with proper audit trails. It's a variant on the old If you have to ask how much, you can't afford it, just in this case If you have to ask why they're bad, you're not qualified to do it right. (Also - note that if you consider the set of computers in the same administrative domain as a whole, your system is *STILL* login as another user, then as root - just that the first login is happening on another system. You're not doing a direct login to root when viewed from the context of the administrative domain as a whole.) pgpGA883f8zkM.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Remote Sql Injection in EasyMoblog 0.5.1 # 2
Original Advisory Can Be Found at
www.zion-security.com - [advisories].
--
Thanks in advance,
Tal Argoni,CEH
www.zion-security.com
·= Security Advisory =·
Issue: Sql injection Vulnerability in EasyMoblog by Umberto Caldera.
Discovered Date: 30/01/07
Author: Tal Argoni, LegendaryZion. [talargoni at gmail.com]
Product Vendor: http://sourceforge.net/project/showfiles.php?group_id=88633
Ver: easymoblog-0.5.1
Details:
EasyMoblog is prone to a Sql Injection Vulnerability.
The vulnerability exists in comment_add function, caused by the lack of
Input Validation/Filtering of quotation and malicious characters
in the GET parameter i OR in the POST parameter post_id.
The use of post_details function is done by add_comment.php
that exist in libraries.inc.php.
Contents of libraries.inc.php:
-
...
function comment_add ($comment) { .
$query =
insert into .CFG_MYSQL_TABPREFIX.comments
(comment_author,comment_author_email,comment_text,comment_added,post_id)
values (
'.addslashes($comment['comment_author']).',
'.addslashes($comment['comment_author_email']).',
'.addslashes($comment['comment_text']).',
'.time().',
'.$comment['post_id'].'
)
;
$res = mysql_query($query);
...
Contents of add_comment.php:
-
...
$form['post_id'] = '';
if(isset($_POST['post_id']))$form['post_id'] =
$_POST['post_id'];
elseif(isset($_GET['i'])) $form['post_id'] = $_GET['i'];
elseexit();
.
if (count($errors) == 0) {
$comment = $form;
$comment = comment_add ($comment);
Header (Location: list_comments.php?i=.$comment['post_id']);
exit();
...
Exploitation URL:
http://www.example.com/easymoblog/add_comment.php?i='[SQL]
Successful exploitation may allow execution of Sql code.
This could also be exploited to get the passwords, users
and a lot of informaion, commit Denial Of Service attacks and more...
Proof Of Concept:
http://www.example.com/easymoblog/add_comment.php?i='[SQL]
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Xss Vulnerability in EasyMoblog 0.5.1
Original Advisory Can Be Found at www.zion-security.com - [advisories]. -- Thanks in advance, Tal Argoni,CEH www.zion-security.com ·= Security Advisory =· Issue: Cross Site Scripting (XSS) Vulnerability in img.php by Umberto Caldera. Discovered Date: 30/01/2007 Author: Tal Argoni [talargoni at gmail d0t com] Product Vendor: http://sourceforge.net/project/showfiles.php?group_id=88633 Ver: easymoblog-0.5.1 Details: EasyMoblog is prone to a Cross Site Scripting Vulnerability. The vulnerability exists in img.php file, caused by the lack of Input Validation/Filtering of quotation and HTML characters in the GET parameter i. Contents of img.php - ... ?php $img_name = $_GET['i']; ? ... body img src=img/posts/?php echo $img_name; ? border=0 alt= / /body ... Exploitation URL: http://www.example.com/easymoblog/img.php?i=;scriptalert(document.cookie);/scriptimg src= Successful exploitation may allow execution of script code. This could also be exploited to spoof the entire website's content, create fake login menu's for all the platform's users, commit Denial Of Service attacks and more... Proof Of Concept: http://www.example.com/easymoblog/img.php?i=;scriptalert(document.cookie);/scriptimg src= ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Remote Sql Injection in EasyMoblog 0.5.1
Original Advisory Can Be Found at
www.zion-security.com - [advisories].
--
Thanks in advance,
Tal Argoni,CEH
www.zion-security.com
·= Security Advisory =·
Issue: Sql injection Vulnerability in EasyMoblog by Umberto Caldera.
Discovered Date: 30/01/07
Author: Tal Argoni, LegendaryZion. [talargoni at gmail.com]
Product Vendor: http://sourceforge.net/project/showfiles.php?group_id=88633
Ver: easymoblog-0.5.1
Details:
EasyMoblog is prone to a Sql Injection Vulnerability.
The vulnerability exists in post_details function, caused by the
lack of Input Validation/Filtering of quotation and malicious
characters in the GET parameter i.
The use of post_details function is done by list_comments.php
that exist in libraries.inc.php.
Contents of libraries.inc.php:
-
...
function post_details ($post_id) {
if (CFG_USE_PATH_INFO == 'no')
$iisbug = '?';
else
$iisbug = '';
$query =
select p.*, count(c.post_id) as post_comments,
count(tr.post_id) as post_trackback_pings, t.topic_name,
concat(t.img_id,'.',i.img_extension) as topic_img
from.CFG_MYSQL_TABPREFIX.posts p
left join .CFG_MYSQL_TABPREFIX.comments c
on p.post_id = c.post_id
left join .CFG_MYSQL_TABPREFIX.trackback_pings tr
on p.post_id = tr.post_id
left join .CFG_MYSQL_TABPREFIX.topics t
on p.topic_id = t.topic_id
left join .CFG_MYSQL_TABPREFIX.images i
on t.img_id = i.img_id
where p.post_id = '.$post_id.'
group byp.post_id
;
$res = mysql_query($query);
...
Contents of list_comments.php:
-
...
$post_id = '';
if (isset($_GET['i']))$post_id = $_GET['i'];
$post = post_details ($post_id);
...
Exploitation URL:
http://www.example.com/easymoblog/list_comments.php?i='[SQL]
Successful exploitation may allow execution of Sql code.
This could also be exploited to get the passwords, users,
and a lot of informaion, commit Denial Of Service attacks and more...
Proof Of Concept:
http://www.example.com/easymoblog/list_comments.php?i='[SQL]
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [TAUSEC] Next meeting of TAUSEC on Feb 11, 6 P.M
The Security Forum, TAUSEC at Tel Aviv University, next lecture will be on Feb 11 at 18:00 (6 P.M) Location: Tel Aviv University Lev Auditorium Map: http://www2.tau.ac.il/map/unimapl1.asp Attendance is free, light refreshments will be served Schedule: - 18:00 Economic analysis of globally deployed attach counter-measures - Shachar Shemesh Lecture level: high level, no technical knowledge required Abstract: The lecturer will try to prove, using nothing but a few hand gestures and 12 coins, that the time is not yet ripe to deploy outgres filtering world wide. We will try to analyze what may cause the balance to tip, and will outline the lecturer very private, and somewhat insane, idea of how the world will slowly change once the tipping point arrives. 19:00 - Break 19:20 - IE Exploits Treats - History, JavaScript evasion techniques, Heap Spray, Ajax worms - Dror Shalev Level: Technical / Very High Level Title: IE Exploits Treats - History, JavaScript evasion techniques, Heap Spray, Ajax worms In the IE Exploits Treats I will show lots of code and techniques , but will not include 0 days exploits. The JavaScript evasion techniques research include the following demos : http://www.drorshalev.com/dev/metascripts/ the History section include : https://secure11.brinkster.com/drorshalev/checkpoint/products/main.htm the Heap Spray include : Internet Exploiter , PwnZilla By SkyLined MS07-004 VML integer overflow exploit , Moti Joseph browserfun by HDM , metasploit setRequestHeader(), setSlice(), createTextRange() the Ajax worms include : An analysis of the 180 Solutions Trojan - 2003 Yahoo Hotmail Potential web-based e-mail worm - 2003 Samy is my Hero -MySpace - 2005 Visit our web site at: http://www.cs.tau.ac.il/tausec/ C U, Eddie ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Hushmail from [EMAIL PROTECTED]
You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ 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] Hushmail from [EMAIL PROTECTED]
WTF? -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens [EMAIL PROTECTED] Verzonden: vrijdag, februari 2007 10:45 Aan: full-disclosure@lists.grok.org.uk Onderwerp: [Full-disclosure] Hushmail from [EMAIL PROTECTED] You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] Vista Speech recognition
--- Posting of your message titled Re[2]: [Dailydave] Vista speach recognition has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: No reason given --- Dear George, With all due respect, I think you are crying wolf a tad bit too much. Speech recognition is inherently unreliable, (btw remember the presentation they gave?). Since you deem the problem as remotely exploitable,let's ignore for one that I have to actively browse to a website and as such be physically in front of the PC and assume we use XSS to zombie the browser and play the audio 5 minutes later. Then we assume there is not too much background noise, assume the audio level is ok, assume the microphone is on, assume Speech recognition is used, assume audio is on, and so forth. Too many assumption to make it a real risk for me remotely, sorry. That's my personal opinion. Is is a vulnerability ? Yes. Is it likely to work 100% like a good crafted exploit? No GO So GO I'm asking Microsoft to reconsider their stance that there is little if any GO need to worry and implement some sort of safety mechanism rather than GO relying on the user to be self vigilant. It doesn't matter that there GO aren't that many people using this feature; Microsoft should fix it if GO they're going to offer it and market it as a key Vista advantage. I have not read they don't plan to, it's just that .. well they don't consider it an emergency, and I can understand. The thing is they have a different scale than you, the next wormable exploit is something they worry about, an exploit that immediately might compromise a system is something I think they rate as Important, this thing is exploitable only if X+n conditions are met, if x+n assumptions are made. I don't say it's not a problem, I say the probability of it being a problem for a defined person is low to very low. GO Since GO Microsoft is promoting Voice recognition for healthcare, we should consider GO the safety of patient health records. [X] Hysteria GO At present time, Vista Speech Recognition wakes up to the command start GO listening. How hard would it be for Microsoft to make that a GO user-definable phrase or word? For example: A user would pick Zelda as GO the word to wake speech mode while someone else picks 439 as their wake GO word. How hard would it be for Microsoft to implement a wake timeout so GO that Speech Recognition would sleep after 5 minutes idle? I haven't seen any mention that they don't plan to do so, maybe I have not read everything. My opinion: they will implement this, BUT hopefully make it an option. GO I'm also running a poll at the end asking if Microsoft should patch this GO with a pass phrase and echo cancellation. Why would that make sense? People will vote for a fix. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ 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] Vista Speech recognition
On Fri, 02 Feb 2007 16:23:24 +0100, Thierry Zoller said: With all due respect, I think you are crying wolf a tad bit too much. Speech recognition is inherently unreliable, (btw remember the presentation they gave?). Since you deem the problem as remotely exploitable,let's ignore for one that I have to actively browse to a website and as such be physically in front of the PC and assume we use XSS to zombie the browser and play the audio 5 minutes later. Then we assume there is not too much background noise, assume the audio level is ok, assume the microphone is on, assume Speech recognition is used, assume audio is on, and so forth. Too many assumption to make it a real risk for me remotely, sorry. That's my personal opinion. Is is a vulnerability ? Yes. Is it likely to work 100% like a good crafted exploit? No On the other hand, it's the sort of attack that is really handy to have if you're doing a targeted attack against a corporation - send a crafted spam that delivers the XSS to zombie the box, sleep for a few hours, and when nobody's left in the office, crank up the volume and yell PANTS DOWN! to every computer within range :) (Remember - the average office is nice and quiet at 11PM if the janitors aren't around - and nobody ever *said* the computer making the noise was the one getting pwned... :) pgpdtNaoDHolL.pgp Description: PGP signature ___ 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] [Full-Disclosure] (Psexec on *NIX)
On 2/2/07, Raj Mathur [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 02 February 2007 12:08, [EMAIL PROTECTED] wrote: On Fri, 02 Feb 2007 13:25:11 +0800, Eduardo Tongson said: On 2/2/07, Xavier Beaudouin [EMAIL PROTECTED] wrote: Allowing direct root login even with SSH is IMHO stupid... Please elaborate why is it IYHO stupid. In environments where more than 1 person has root access, allowing direct login to root means you can't keep an audit trail of which person logged in. And if your environment only one person has root access, that's just looking for a DoS if the one person is hit by a bus. I believe we have had this discussion before, but I'll iterate my beliefs in favour of allowing direct root access again: - - Password management is a bitch. I don't remember passwords for about half the accounts I have. Using a key-based root login, I don't need to remember those passwords either. If you take the sudo route, every user has to remember each password for each account, unless you take the deprecated route of reusing passwords (or *horrors* allow sudo without password). key-based login without passphrase is like eating cheese without bred. useless (IMHO). - - With a little bit of configuration, it's easy to figure out which key was used to login to an account; the audit trail can be managed that way. - - Managing which users have access to which root accounts is trivial this way: just add or delete their keys from .ssh/authorized_keys[2]. Totally agree. -- Tyop? http://altmylife.blogspot.com ___ 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] Hushmail from [EMAIL PROTECTED]
Again WTF! On 2/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You have received mail at your Hushmail address. To cease receiving these notices, click the Preferences link in the toolbar once you have logged in. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://www.goldwatches.com http://www.wazoozle.com ___ 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] [Full-Disclosure] (Psexec on *NIX)
On Fri, Feb 02, 2007 at 04:51:36PM +0100, Tyop? wrote: On 2/2/07, Raj Mathur [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 02 February 2007 12:08, [EMAIL PROTECTED] wrote: On Fri, 02 Feb 2007 13:25:11 +0800, Eduardo Tongson said: On 2/2/07, Xavier Beaudouin [EMAIL PROTECTED] wrote: Allowing direct root login even with SSH is IMHO stupid... Please elaborate why is it IYHO stupid. In environments where more than 1 person has root access, allowing direct login to root means you can't keep an audit trail of which person logged in. And if your environment only one person has root access, that's just looking for a DoS if the one person is hit by a bus. I believe we have had this discussion before, but I'll iterate my beliefs in favour of allowing direct root access again: - - Password management is a bitch. I don't remember passwords for about half the accounts I have. Using a key-based root login, I don't need to remember those passwords either. If you take the sudo route, every user has to remember each password for each account, unless you take the deprecated route of reusing passwords (or *horrors* allow sudo without password). key-based login without passphrase is like eating cheese without bred. useless (IMHO). - - With a little bit of configuration, it's easy to figure out which key was used to login to an account; the audit trail can be managed that way. - - Managing which users have access to which root accounts is trivial this way: just add or delete their keys from .ssh/authorized_keys[2]. Totally agree. -- Tyop? http://altmylife.blogspot.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ... i eat cheese without bread -- ___ |hello, my name is | | .__ .___ .___| | | |__ __| _/__| _/___ | |_/ ___\| | \_/ __ \ / __ |/ __ |/ __ \_ __ \| |\ \___| Y \ ___// /_/ / /_/ \ ___/| | \/| | \___ ___| /\___ \ |\___ __| | |\/ \/ \/ \/\/\/| |http://chedder.hacked.in | |___| You don't exist. Go away pgpjcYrxgZTvA.pgp Description: PGP signature ___ 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] Vista Speech recognition
This is great! On 2/2/07, Thierry Zoller [EMAIL PROTECTED] wrote: --- Posting of your message titled Re[2]: [Dailydave] Vista speach recognition has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: No reason given --- Dear George, With all due respect, I think you are crying wolf a tad bit too much. Speech recognition is inherently unreliable, (btw remember the presentation they gave?). Since you deem the problem as remotely exploitable,let's ignore for one that I have to actively browse to a website and as such be physically in front of the PC and assume we use XSS to zombie the browser and play the audio 5 minutes later. Then we assume there is not too much background noise, assume the audio level is ok, assume the microphone is on, assume Speech recognition is used, assume audio is on, and so forth. Too many assumption to make it a real risk for me remotely, sorry. That's my personal opinion. Is is a vulnerability ? Yes. Is it likely to work 100% like a good crafted exploit? No GO So GO I'm asking Microsoft to reconsider their stance that there is little if any GO need to worry and implement some sort of safety mechanism rather than GO relying on the user to be self vigilant. It doesn't matter that there GO aren't that many people using this feature; Microsoft should fix it if GO they're going to offer it and market it as a key Vista advantage. I have not read they don't plan to, it's just that .. well they don't consider it an emergency, and I can understand. The thing is they have a different scale than you, the next wormable exploit is something they worry about, an exploit that immediately might compromise a system is something I think they rate as Important, this thing is exploitable only if X+n conditions are met, if x+n assumptions are made. I don't say it's not a problem, I say the probability of it being a problem for a defined person is low to very low. GO Since GO Microsoft is promoting Voice recognition for healthcare, we should consider GO the safety of patient health records. [X] Hysteria GO At present time, Vista Speech Recognition wakes up to the command start GO listening. How hard would it be for Microsoft to make that a GO user-definable phrase or word? For example: A user would pick Zelda as GO the word to wake speech mode while someone else picks 439 as their wake GO word. How hard would it be for Microsoft to implement a wake timeout so GO that Speech Recognition would sleep after 5 minutes idle? I haven't seen any mention that they don't plan to do so, maybe I have not read everything. My opinion: they will implement this, BUT hopefully make it an option. GO I'm also running a poll at the end asking if Microsoft should patch this GO with a pass phrase and echo cancellation. Why would that make sense? People will vote for a fix. -- http://secdev.zoller.lu Thierry Zoller Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://www.goldwatches.com http://www.wazoozle.com ___ 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] [Full-Disclosure] (Psexec on *NIX)
On 2/2/07, Tyop? [EMAIL PROTECTED] wrote: key-based login without passphrase is like eating cheese without bred. useless (IMHO). Totally, if someone compromises the machine and gets root they get all your keys and without a passphrase... yeah no good. - - With a little bit of configuration, it's easy to figure out which key was used to login to an account; the audit trail can be managed that way. - - Managing which users have access to which root accounts is trivial this way: just add or delete their keys from .ssh/authorized_keys[2]. Totally agree. Ditto. -sb -- Tyop? http://altmylife.blogspot.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] Hushmail from [EMAIL PROTECTED]
On 2/2/07, James Matthews [EMAIL PROTECTED] wrote: Again WTF! It's just someone trying to get hushmail filtered from full-disclosure. ___ 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] Hushmail from [EMAIL PROTECTED]
Mike Owen wrote: On 2/2/07, James Matthews [EMAIL PROTECTED] wrote: Again WTF! It's just someone trying to get hushmail filtered from full-disclosure. This may backfire, as it seems Full Disclosure doesn't filter anything... Matthew Flaschen signature.asc Description: OpenPGP digital signature ___ 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] JavaScript inLine Debugger - The fastest web sites debugger (technique, not a tool)
SirDarckCat wrote: JaSiLDBG JavaScript inLine Debugger We wrote a document, explaining some of the capacities of this technique, and in the meantime, we also created some functions in a library that can help you using JaSiLDBG. The library is named: estigma its instalation, is very simple, just clicking a bookmark, in any browser that supports javascript will load it, and you can start using it. Thank you. I had forgotten how to execute statements without destroying the page (put it in void()). Matthew Flaschen signature.asc Description: OpenPGP digital signature ___ 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] Vista Speech recognition
If you have to use a side channel attack to ensure that the microphone is on and the speakers are active (what ideal target environment will have them both enabled or even fitted? No, I don't believe healthcare will be one), why don't you just use that channel to launch the primary attack? While there is a real concern about this issue, that is all it is - a concern. I agree with Thierry that this is a low risk situation. It will be fun for pranking and the occasional exploit (hmm, it appears my drink holder has been replaced with a credit card slot on my computer), but will be harmless for most. It will be more fun to bind sound to system events, so that every time a dialogue box was presented the system helpfully shouts out 'Cancel'. Okay, so Microsoft's implementation of this feature could have been somewhat better, but it isn't really worth the hype and coverage that it has received to date. Carl Sûnnet Beskerming Pty. Ltd. Adelaide, Australia http://www.beskerming.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [ MDKSA-2007:031 ] - Updated kdelibs packages fix KHTML vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:031 http://www.mandriva.com/security/ ___ Package : kdelibs Date: February 2, 2007 Affected: 2007.0, Corporate 3.0, Corporate 4.0 ___ Problem Description: FIXME Konqueror 3.5.5 does not properly parse HTML comments in title tags, which allows remote attackers to conduct cross-site scripting (XSS) attacks and bypass some XSS protection schemes by embedding certain HTML tags within a comment, a related issue to CVE-2007-0478. Updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0537 ___ Updated Packages: Mandriva Linux 2007.0: 7882590402c82ff347205c176380153e 2007.0/i586/kdelibs-common-3.5.4-19.2mdv2007.0.i586.rpm 01c4eb64ef06a8a8759843be0c07a920 2007.0/i586/kdelibs-devel-doc-3.5.4-19.2mdv2007.0.i586.rpm e63e9a2d3a07d3f2cfa20e495a5b1010 2007.0/i586/libkdecore4-3.5.4-19.2mdv2007.0.i586.rpm 1ad276143d78de84b08606a815eecda9 2007.0/i586/libkdecore4-devel-3.5.4-19.2mdv2007.0.i586.rpm 34ee09ad1644f5685f6ebb6e7e214939 2007.0/SRPMS/kdelibs-3.5.4-19.2mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: 081d768881b4f012e75854738189327d 2007.0/x86_64/kdelibs-common-3.5.4-19.2mdv2007.0.x86_64.rpm 051e3625e87627e52c47590961523b51 2007.0/x86_64/kdelibs-devel-doc-3.5.4-19.2mdv2007.0.x86_64.rpm 6a2b0171144925bd21073553816f33b1 2007.0/x86_64/lib64kdecore4-3.5.4-19.2mdv2007.0.x86_64.rpm ae2202556fccf0bb820ed3e8401825ec 2007.0/x86_64/lib64kdecore4-devel-3.5.4-19.2mdv2007.0.x86_64.rpm 34ee09ad1644f5685f6ebb6e7e214939 2007.0/SRPMS/kdelibs-3.5.4-19.2mdv2007.0.src.rpm Corporate 3.0: 6afd1be3e42d77e131e44f9ed969c80e corporate/3.0/i586/kdelibs-common-3.2-36.17.C30mdk.i586.rpm c00a10231de66159fecb2106e56ec1ca corporate/3.0/i586/libkdecore4-3.2-36.17.C30mdk.i586.rpm 733852a68f994ace4eb35017342443fb corporate/3.0/i586/libkdecore4-devel-3.2-36.17.C30mdk.i586.rpm 4d4c9fee93b93f2c76f5092ff5ef23f3 corporate/3.0/SRPMS/kdelibs-3.2-36.17.C30mdk.src.rpm Corporate 3.0/X86_64: 418170a92387d41c49f3d32c91c97c9b corporate/3.0/x86_64/kdelibs-common-3.2-36.17.C30mdk.x86_64.rpm 590e047f677eb717c40a9e2fd77590e8 corporate/3.0/x86_64/lib64kdecore4-3.2-36.17.C30mdk.x86_64.rpm ec04fe80ee4a983e1ad98f54d75681af corporate/3.0/x86_64/lib64kdecore4-devel-3.2-36.17.C30mdk.x86_64.rpm 4d4c9fee93b93f2c76f5092ff5ef23f3 corporate/3.0/SRPMS/kdelibs-3.2-36.17.C30mdk.src.rpm Corporate 4.0: 2dc94e4e225b74d3f2e283b04c836273 corporate/4.0/i586/kdelibs-arts-3.5.4-2.3.20060mlcs4.i586.rpm 826d76e2f3d50f48513ed18c4360dd67 corporate/4.0/i586/kdelibs-common-3.5.4-2.3.20060mlcs4.i586.rpm f7dad3711d9406d1123428f2c0cd9453 corporate/4.0/i586/kdelibs-devel-doc-3.5.4-2.3.20060mlcs4.i586.rpm 88f0164705a9d71f21c3c4edfe7822b2 corporate/4.0/i586/libkdecore4-3.5.4-2.3.20060mlcs4.i586.rpm e00f903a3c51a747a694e3ab32c7 corporate/4.0/i586/libkdecore4-devel-3.5.4-2.3.20060mlcs4.i586.rpm 79690e9ab56836b4adc7a4d59bb872db corporate/4.0/SRPMS/kdelibs-3.5.4-2.3.20060mlcs4.src.rpm Corporate 4.0/X86_64: 88d9b2f945bd62aa89b5f7743320cc0a corporate/4.0/x86_64/kdelibs-arts-3.5.4-2.3.20060mlcs4.x86_64.rpm c1e462eaeb2127939d0d3775fb7a04a4 corporate/4.0/x86_64/kdelibs-common-3.5.4-2.3.20060mlcs4.x86_64.rpm a559376fde6f8513904010fc377293e7 corporate/4.0/x86_64/kdelibs-devel-doc-3.5.4-2.3.20060mlcs4.x86_64.rpm d97e4c4dd9859b6e43f3399e3e2c5fa1 corporate/4.0/x86_64/lib64kdecore4-3.5.4-2.3.20060mlcs4.x86_64.rpm f3e43bca041aeca542bba33a0bac1d43 corporate/4.0/x86_64/lib64kdecore4-devel-3.5.4-2.3.20060mlcs4.x86_64.rpm 79690e9ab56836b4adc7a4d59bb872db corporate/4.0/SRPMS/kdelibs-3.5.4-2.3.20060mlcs4.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux)
[Full-disclosure] [ MDKSA-2007:032 ] - Updated mpg123 packages fix DoS vulnerability.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:032 http://www.mandriva.com/security/ ___ Package : mpg123 Date: February 2, 2007 Affected: 2006.0, 2007.0, Corporate 3.0 ___ Problem Description: The http_open function in httpget.c in mpg123 before 0.64 allows remote attackers to cause a denial of service (infinite loop) by closing the HTTP connection early. Packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0578 ___ Updated Packages: Mandriva Linux 2006.0: babe8d78bc25c2dd132fa920880ba753 2006.0/i586/mpg123-0.59r-23.2.20060mdk.i586.rpm ba97940bced19952befcacd2f3543adf 2006.0/SRPMS/mpg123-0.59r-23.2.20060mdk.src.rpm Mandriva Linux 2006.0/X86_64: df5b4948cc199f99cb922c501529ea6d 2006.0/x86_64/mpg123-0.59r-23.2.20060mdk.x86_64.rpm ba97940bced19952befcacd2f3543adf 2006.0/SRPMS/mpg123-0.59r-23.2.20060mdk.src.rpm Mandriva Linux 2007.0: 63d1e8b57d1883657612bc4655ef9479 2007.0/i586/mpg123-0.60-2.1mdv2007.0.i586.rpm 6e6643dbbb5f0f837af32ca764568189 2007.0/SRPMS/mpg123-0.60-2.1mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: a84d45f47bcb660148c1a8294b4aec65 2007.0/x86_64/mpg123-0.60-2.1mdv2007.0.x86_64.rpm 6e6643dbbb5f0f837af32ca764568189 2007.0/SRPMS/mpg123-0.60-2.1mdv2007.0.src.rpm Corporate 3.0: b4f1ca196054a9d7e40359bd15bcf708 corporate/3.0/i586/mpg123-0.59r-22.4.C30mdk.i586.rpm 396f3b1659f5ea06471b8c8f4a077043 corporate/3.0/SRPMS/mpg123-0.59r-22.4.C30mdk.src.rpm Corporate 3.0/X86_64: 893735fab9e27cd51cac70f64f4aa831 corporate/3.0/x86_64/mpg123-0.59r-22.4.C30mdk.x86_64.rpm 396f3b1659f5ea06471b8c8f4a077043 corporate/3.0/SRPMS/mpg123-0.59r-22.4.C30mdk.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFw6jrmqjQ0CJFipgRAnS4AJ9nSuXylv+q+NanqNWUpwi+5F+K/ACeJZNc QipMayieg+BkKXqXt6bvWMc= =AuJY -END PGP SIGNATURE- ___ 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] [Full-Disclosure] (Psexec on *NIX)
On 2/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Fri, Feb 02, 2007 at 04:51:36PM +0100, Tyop? wrote: On 2/2/07, Raj Mathur [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 02 February 2007 12:08, [EMAIL PROTECTED] wrote: On Fri, 02 Feb 2007 13:25:11 +0800, Eduardo Tongson said: On 2/2/07, Xavier Beaudouin [EMAIL PROTECTED] wrote: Allowing direct root login even with SSH is IMHO stupid... Please elaborate why is it IYHO stupid. In environments where more than 1 person has root access, allowing direct login to root means you can't keep an audit trail of which person logged in. And if your environment only one person has root access, that's just looking for a DoS if the one person is hit by a bus. I believe we have had this discussion before, but I'll iterate my beliefs in favour of allowing direct root access again: - - Password management is a bitch. I don't remember passwords for about half the accounts I have. Using a key-based root login, I don't need to remember those passwords either. If you take the sudo route, every user has to remember each password for each account, unless you take the deprecated route of reusing passwords (or *horrors* allow sudo without password). key-based login without passphrase is like eating cheese without bred. useless (IMHO). - - With a little bit of configuration, it's easy to figure out which key was used to login to an account; the audit trail can be managed that way. - - Managing which users have access to which root accounts is trivial this way: just add or delete their keys from .ssh/authorized_keys[2]. Totally agree. ... i eat cheese without bread It's dangerous. -- Tyop? http://altmylife.blogspot.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
