From: "Hullinger, Jason (Cloud Services)" <jason.hullinger@hp.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: "stgt@vger.kernel.org" <stgt@vger.kernel.org>
Subject: Re: tgtd buffer overflow and command injection vulnerabilities
Date: Tue, 17 Jun 2014 22:17:49 +0000 [thread overview]
Message-ID: <CFC5EC3A.12946%jason.hullinger@hp.com> (raw)
In-Reply-To: <CFC49B25.128EF%jason.hullinger@hp.com>
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
While looking into making a patch for this issue I have found another
buffer overflow in iscsi/target.c for the same callback feature in the
function target_redirected:
char dst[INET6_ADDRSTRLEN], in_buf[1024];
...
p = in_buf;
p += sprintf(p, "%s ", target->redirect_info.callback);
p += sprintf(p, "%s ", tgt_targetname(target->tid));
...
sprintf(p, "%s", dst);
Where target->redirect_info.callback is char buffer set by user input and
can easily be over 1024 characters. Having gone over these functions I'm
not exactly clear what it's purpose is, so perhaps someone on the tgt side
would be better suited to fix these issues. I would recommend not using
sprintf (or other such unsafe functions) throughout the tgt project and at
least using snprintf instead.
Thanks,
Jason Hullinger
On 6/16/14, 1:06 PM, "Hullinger, Jason (Cloud Services)"
<jason.hullinger@hp.com> wrote:
>Hi,
>
>Thanks for the clarification, and I see you are using a domain socket at
>/var/run/tgtd.ipc_abstract_namespace.X Since the overflow occurs in a
>function that is expected to do arbitrary commands it's sort of redundant
>as a security issue. It is a bug though and will cause the process to
>break so it should still be fixed.
>
>Thanks,
>
>Jason Hullinger
>
>On 6/14/14, 6:29 AM, "FUJITA Tomonori" <fujita.tomonori@lab.ntt.co.jp>
>wrote:
>
>>Sorry about the delay,
>>
>>On Tue, 10 Jun 2014 19:17:35 +0000
>>"Hullinger, Jason (Cloud Services)" <jason.hullinger@hp.com> wrote:
>>
>>> The function call_program in the tgtd daemon includes a callback
>>>function
>>> that will run arbitrary commands. Additionally, it does not check that
>>>the
>>
>>Yeah, the feature is intentional:
>>
>>http://www.spinics.net/lists/linux-stgt/msg02065.html
>>
>>No security about tgtadm. A user who can use tgtadm has the root
>>permission. He can do whatever he want to on the machine. He doesn't
>>need to use a security hole in tgtd and tgtadm.
>>
>>Of course, we care about security about iscsi and isns ports.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5475 bytes --]
prev parent reply other threads:[~2014-06-17 22:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 19:17 tgtd buffer overflow and command injection vulnerabilities Hullinger, Jason (Cloud Services)
2014-06-13 2:27 ` Hitoshi Mitake
2014-06-13 19:23 ` Hullinger, Jason (Cloud Services)
2014-06-14 13:29 ` FUJITA Tomonori
2014-06-16 20:06 ` Hullinger, Jason (Cloud Services)
2014-06-17 22:17 ` Hullinger, Jason (Cloud Services) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CFC5EC3A.12946%jason.hullinger@hp.com \
--to=jason.hullinger@hp.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=stgt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).