On Sunday 04 March 2007, Anthony Lamantia wrote:
> >In this case, we took the action to document that it was fixed and told
> >users they should upgrade (and why), because I don't believe this
> >particular issue was reported by an auditing company
>
> it would have been nice to know a problem exis
Anthony Lamantia wrote:
> it would have been nice to know a problem existed in chan_sip (on the
> website, without having to ask or searching the commits list) and great
> if a advisory was posted to one or all of the popular security mailing
> lists.
The fixed versions of Asterisk were posted wi
In this case, we took the action to document that it was fixed and told
users they should upgrade (and why), because I don't believe this
particular issue was reported by an auditing company
it would have been nice to know a problem existed in chan_sip (on the
website, without having to ask or s
Matthew Rubenstein wrote:
> This security reality is well known in the programming industry. I'm
> disappointed to see Digium acting as if it weren't.
What is obscured? We clearly stated that the vulnerability existed, the
patch to fix it was public, the release that contained that patch was
Securing an open project (or even a closed one) by keeping known
exploits "secret" is well known to be a failing strategy. The bad guys
are at least as likely as anyone else to have discovered it. And at
least as motivated to monitor the patches for the exploit. Keeping the
exploit "secret"
Thank you for your reply Bryant. Just to clear things up a bit more.
When that *inbound* channel creates an outbound channel, does that
outbound channel has its own thread too?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Russell
Bryant
Sent: Sunday, M
the paper *Audio and the Graphics Processing Unit *(
http://www.node99.org/projects/gpuaudio/ ) may be of some usefulness to you,
it's not the most positive paper considering what you want to do but eh,
it's something... http://www.gpgpu.org/ also has a lot of resources that you
might want to chec
Compression algorithms have generally not been ported to GPUs like the
G80. They're usually more logic and branch oriented than just brute
force multiply-accumulates that GPUs specialize in. I also haven't seen
any of the popular Asterisk codecs, like G.729 or GSM, ported to any
GPU. Is the
Anthony Lamantia wrote:
> "obvious reasons" .. ?, I really would like to know what the risk to my
> asterisk servers are.
We have never, and will never, help potential exploiters directly.
The issue is that a very simple SIP packet can cause Asterisk to crash.
Figuring out how to construct that
"obvious reasons" .. ?, I really would like to know what the risk to my
asterisk servers are.
On 3/4/07, Russell Bryant <[EMAIL PROTECTED]> wrote:
Anthony Lamantia wrote:
> where can i find more information regarding it (protocol, is it a
> problem before authentication is required..etc)
Det
Wai Wu wrote:
1) Is each channel use their own thread if a codec is used?
Each *inbound* channel uses it's own thread. The inbound channel then executes
dialplan applications, which may then create an outbound channel. In that case,
you then have these two channels in the same thread. This
Anthony Lamantia wrote:
where can i find more information regarding it (protocol, is it a
problem before authentication is required..etc)
Details of how to exploit the problem are intentionally hard to find, for
obvious reasons.
--
Russell Bryant
Software Engineer
Digium, Inc.
begin:vcard
fn
Again i found that there is no asterisk-addons-1.4-current although we
have asterisk-1.4-current and zaptel-1.4-current and so forth...
cheers,
Christian
Christian wrote:
Hi guys,
for the "current" zaptel package there is a zaptel-current-1.2.tar.gz
on ftp.digium.com/zaptel, but unfortunat
13 matches
Mail list logo
