F
forceten32
I have been resisting this compression. Are there any security concerns?
What's the easiest way to read it?
Thanks,
Fred
What's the easiest way to read it?
Thanks,
Fred
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
T
TDP
forceten32 said:I have been resisting this compression. Are there any security concerns?
What's the easiest way to read it?
Thanks,
Fred
Fred, As far as I am aware its more of an encoding/encription programme used
by some rather unsavoury newsgroups to disguise the content of binary and
movie files.
The only newsreader that I am aware of that can unencrypt these files is
XNews..
Tdp..
Y
Yves Leclerc
yEnc is not a compression used for files storage. It is mainly used for
sending files over the Usenet newsgroups and is very propular with image
transfers.
sending files over the Usenet newsgroups and is very propular with image
transfers.
D
David H. Lipman
From: "TDP" <[email protected]>
|
| Fred, As far as I am aware its more of an encoding/encription programme used
| by some rather unsavoury newsgroups to disguise the content of binary and
| movie files.
| The only newsreader that I am aware of that can unencrypt these files is
| XNews..
| Tdp..
There is FidoLook !
http://www.fidolook.org/
It has nothing to do "unsavoury newsgroups". It is an alternate ecoding method that has
less overhaed and greater compression than the standard encoding method use by News Clients.
|
| Fred, As far as I am aware its more of an encoding/encription programme used
| by some rather unsavoury newsgroups to disguise the content of binary and
| movie files.
| The only newsreader that I am aware of that can unencrypt these files is
| XNews..
| Tdp..
There is FidoLook !
http://www.fidolook.org/
It has nothing to do "unsavoury newsgroups". It is an alternate ecoding method that has
less overhaed and greater compression than the standard encoding method use by News Clients.
K
Ken Blake, MVP
TDP said:Fred, As far as I am aware its more of an encoding/encription
programme used by some rather unsavoury newsgroups to disguise the
content of binary and movie files.
No, this is incorrect and very misleading. It has nothing to do with
"unsavoury newsgroups," and isn't at all used to disguise anything. yEnc is
a perfectly legitimate encoding/compression method widely used for binary
files of many types.
True, some of those binary files may be pictures of things that you consider
"unsavoury," but that's far from true in general. yEnc is also used, for
example, to encode music files in binary music newsgroups. You may not like
Beetthoven and Mozart, but please don't call them "unsavoury."
The only newsreader that I am aware of that can unencrypt these files
is XNews..
No, there are *many* newsreaders than can handle yEnc files. Do a Google
search on yenc newsreader to see some of those available.
J
Jone Doe
Read "Why yEnc is bad..." by one of the developers of the system, then makeforceten32 said:I have been resisting this compression. Are there any security concerns?
What's the easiest way to read it?
Thanks,
Fred
your decision.
http://www.exit109.com/~jeremy/news/yenc.html
M
mikeyhsd
check out Yproxy from Brawny lads software.
(e-mail address removed)
I have been resisting this compression. Are there any security concerns?
What's the easiest way to read it?
Thanks,
Fred
(e-mail address removed)
I have been resisting this compression. Are there any security concerns?
What's the easiest way to read it?
Thanks,
Fred
D
Don Taylor
Jone Doe said:Read "Why yEnc is bad..." by one of the developers of the system, then make
your decision.
http://www.exit109.com/~jeremy/news/yenc.html
None of the responses to the original question that I've seen,
and none of the handful of web searches I've done on my own,
seem to address the original question...
Are there any known security holes in yEnc?
I've looked at the source for an early version of one decoder,
which is likely where a security flaw would be exploited on an
end uer system. The whole decoder is under a thousand lines
of code, with substantial whitespace and comments included.
That isn't a trivial sized program, it would be possible for
any number of flaws to be lurking inside something like that,
particularly if it is using support from the OS. But I'm not
qualified to determine whether that is flaw free or not.
I can't find anyone declaring one way or the other. Are there
any known security holes in yEnc?
Thank you
D
David H. Lipman
From: "Don Taylor" <[email protected]>
|
| None of the responses to the original question that I've seen,
| and none of the handful of web searches I've done on my own,
| seem to address the original question...
|
| Are there any known security holes in yEnc?
|
| I've looked at the source for an early version of one decoder,
| which is likely where a security flaw would be exploited on an
| end uer system. The whole decoder is under a thousand lines
| of code, with substantial whitespace and comments included.
| That isn't a trivial sized program, it would be possible for
| any number of flaws to be lurking inside something like that,
| particularly if it is using support from the OS. But I'm not
| qualified to determine whether that is flaw free or not.
|
| I can't find anyone declaring one way or the other. Are there
| any known security holes in yEnc?
|
| Thank you
It's not an encryption methodology. Its an encoding methodology. Therefore where do
security concerns even come into play ?
|
| None of the responses to the original question that I've seen,
| and none of the handful of web searches I've done on my own,
| seem to address the original question...
|
| Are there any known security holes in yEnc?
|
| I've looked at the source for an early version of one decoder,
| which is likely where a security flaw would be exploited on an
| end uer system. The whole decoder is under a thousand lines
| of code, with substantial whitespace and comments included.
| That isn't a trivial sized program, it would be possible for
| any number of flaws to be lurking inside something like that,
| particularly if it is using support from the OS. But I'm not
| qualified to determine whether that is flaw free or not.
|
| I can't find anyone declaring one way or the other. Are there
| any known security holes in yEnc?
|
| Thank you
It's not an encryption methodology. Its an encoding methodology. Therefore where do
security concerns even come into play ?
D
Don Taylor
David H. Lipman said:From: "Don Taylor" <[email protected]>
| None of the responses to the original question that I've seen,
| and none of the handful of web searches I've done on my own,
| seem to address the original question...
|
| Are there any known security holes in yEnc? ....
It's not an encryption methodology. Its an encoding methodology.
Therefore where do security concerns even come into play ?
That one I can answer with a recent example of exactly this problem.
In this
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/sec_gdi.asp
Microsoft claimed
GDI generally has few security concerns because it deals with display
rather than input. However, here are a few issues that you should consider.
Then in
http://www.microsoft.com/athome/security/update/bulletins/200409_jpeg_tool.mspx
they had to backpeddle when they discovered
The GDI+ security update for September 2004 addresses a security
issue in JPEG processing technology.
Now jpg display isn't an encryption methodology, it too is just one
more way of encoding non-executable information, so this analogy
seems very close to the yEnc encoding of non-executable information.
So, it doesn't have to be an encryption tool for some little net vandal
to expose a security problem on your system, almost any program that
wasn't carefully written by someone highly skilled in considering all
the ways that a system can be subverted could be used to compromise
your security.
To be clear, I am NOT claiming that there are any security holes in
yEnc or yDec.
D
David H. Lipman
From: "Don Taylor" <[email protected]>
| That one I can answer with a recent example of exactly this problem.
|
| In this
| http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/sec_gdi.asp
| Microsoft claimed
| GDI generally has few security concerns because it deals with display
| rather than input. However, here are a few issues that you should consider.
|
| Then in
| http://www.microsoft.com/athome/security/update/bulletins/200409_jpeg_tool.mspx
| they had to backpeddle when they discovered
| The GDI+ security update for September 2004 addresses a security
| issue in JPEG processing technology.
|
| Now jpg display isn't an encryption methodology, it too is just one
| more way of encoding non-executable information, so this analogy
| seems very close to the yEnc encoding of non-executable information.
|
| So, it doesn't have to be an encryption tool for some little net vandal
| to expose a security problem on your system, almost any program that
| wasn't carefully written by someone highly skilled in considering all
| the ways that a system can be subverted could be used to compromise
| your security.
|
| To be clear, I am NOT claiming that there are any security holes in
| yEnc or yDec.
The GDI+ isn't a communication protocol. It is a software implementation for rendering
graphics and is common amongst many Microsoft products. I problem can occur where a
spcecially crafted GIF or JPEG graphic can cause a buffer overflow situation in the GDI+
rendering engine and thus could be used to compramise the system by executing some code.
In this case, the yEnc is a protocol for encoding and decoding an encapsulted file(s) and I
don't see how a buffer overflow or other situation could cause a security problem. In that
case, the file would fail to be encoded or fail to be decoded.
|| "David H. Lipman said:|> None of the responses to the original question that I've seen,
|> and none of the handful of web searches I've done on my own,
|> seem to address the original question...
|>
|> Are there any known security holes in yEnc? | ...
| That one I can answer with a recent example of exactly this problem.
|
| In this
| http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/sec_gdi.asp
| Microsoft claimed
| GDI generally has few security concerns because it deals with display
| rather than input. However, here are a few issues that you should consider.
|
| Then in
| http://www.microsoft.com/athome/security/update/bulletins/200409_jpeg_tool.mspx
| they had to backpeddle when they discovered
| The GDI+ security update for September 2004 addresses a security
| issue in JPEG processing technology.
|
| Now jpg display isn't an encryption methodology, it too is just one
| more way of encoding non-executable information, so this analogy
| seems very close to the yEnc encoding of non-executable information.
|
| So, it doesn't have to be an encryption tool for some little net vandal
| to expose a security problem on your system, almost any program that
| wasn't carefully written by someone highly skilled in considering all
| the ways that a system can be subverted could be used to compromise
| your security.
|
| To be clear, I am NOT claiming that there are any security holes in
| yEnc or yDec.
The GDI+ isn't a communication protocol. It is a software implementation for rendering
graphics and is common amongst many Microsoft products. I problem can occur where a
spcecially crafted GIF or JPEG graphic can cause a buffer overflow situation in the GDI+
rendering engine and thus could be used to compramise the system by executing some code.
In this case, the yEnc is a protocol for encoding and decoding an encapsulted file(s) and I
don't see how a buffer overflow or other situation could cause a security problem. In that
case, the file would fail to be encoded or fail to be decoded.
D
Don Taylor
David H. Lipman said:|
| That one I can answer with a recent example of exactly this problem.
|
| In this
| http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/sec_gdi.asp
| Microsoft claimed
| GDI generally has few security concerns because it deals with display
| rather than input. However, here are a few issues that you should consider.
|
| Then in
| http://www.microsoft.com/athome/security/update/bulletins/200409_jpeg_tool.mspx
| they had to backpeddle when they discovered
| The GDI+ security update for September 2004 addresses a security
| issue in JPEG processing technology.
|
| Now jpg display isn't an encryption methodology, it too is just one
| more way of encoding non-executable information, so this analogy
| seems very close to the yEnc encoding of non-executable information.
|
| So, it doesn't have to be an encryption tool for some little net vandal
| to expose a security problem on your system, almost any program that
| wasn't carefully written by someone highly skilled in considering all
| the ways that a system can be subverted could be used to compromise
| your security.
|
| To be clear, I am NOT claiming that there are any security holes in
| yEnc or yDec.
The GDI+ isn't a communication protocol. It is a software
implementation for rendering graphics and is common amongst many
Microsoft products. I problem can occur where a spcecially crafted
GIF or JPEG graphic can cause a buffer overflow situation in the
GDI+ rendering engine and thus could be used to compramise the
system by executing some code.
In this case, the yEnc is a protocol for encoding and decoding an
encapsulted file(s) and I don't see how a buffer overflow or other
situation could cause a security problem. In that case, the file
would fail to be encoded or fail to be decoded.
So a buffer overflow in GDI allowed a specially crafted binary
that you just asked to be decoded instead to sieze control of
your system.
How is this different from the possibility that a buffer overflow
in yDec allowing a specially crafted binary that you just asked
to be deconded instead sieze control of your system.
A buffer overflow is ANY program with a serious bug where bad
input can sieze control of your system.
I'm honestly puzzled how you think this cannot equally apply to
both these programs. A "bad" jpg wouldn't be correctly decoded
by GDI. A "bad" yenc wouldn't be correctly decoded. GDI we
know has this security hole. We don't yet have anyone with an
answer for yDec.
D
David H. Lipman
From: "Don Taylor" <[email protected]>
|
| So a buffer overflow in GDI allowed a specially crafted binary
| that you just asked to be decoded instead to sieze control of
| your system.
|
| How is this different from the possibility that a buffer overflow
| in yDec allowing a specially crafted binary that you just asked
| to be deconded instead sieze control of your system.
|
| A buffer overflow is ANY program with a serious bug where bad
| input can sieze control of your system.
|
| I'm honestly puzzled how you think this cannot equally apply to
| both these programs. A "bad" jpg wouldn't be correctly decoded
| by GDI. A "bad" yenc wouldn't be correctly decoded. GDI we
| know has this security hole. We don't yet have anyone with an
| answer for yDec.
Reference:
http://vil.nai.com/vil/content/v_128356.htm
Microsoft Security Bulletin MS04-028
Buffer Overrun in JPEG Processing Could Allow Code Execution (833987)
http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
There is a big difference. GDI+ is incorporated into the OS and *many* MS products (see
above). Since it is a problem when it is rendering a graphic and the hooks are in the OS
kernel, it can get control. GDI has to look into the grapic coding and interpret it to view
it. It is the rendering engine that can be exploited.
yEnc is a communication protocol and does NOT have hooks in the OS. It is also not MS
Windows specific. You could implement it into Unix/Linux email or news clients or any other
Operating System email or news clients.
|
| So a buffer overflow in GDI allowed a specially crafted binary
| that you just asked to be decoded instead to sieze control of
| your system.
|
| How is this different from the possibility that a buffer overflow
| in yDec allowing a specially crafted binary that you just asked
| to be deconded instead sieze control of your system.
|
| A buffer overflow is ANY program with a serious bug where bad
| input can sieze control of your system.
|
| I'm honestly puzzled how you think this cannot equally apply to
| both these programs. A "bad" jpg wouldn't be correctly decoded
| by GDI. A "bad" yenc wouldn't be correctly decoded. GDI we
| know has this security hole. We don't yet have anyone with an
| answer for yDec.
Reference:
http://vil.nai.com/vil/content/v_128356.htm
Microsoft Security Bulletin MS04-028
Buffer Overrun in JPEG Processing Could Allow Code Execution (833987)
http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx
There is a big difference. GDI+ is incorporated into the OS and *many* MS products (see
above). Since it is a problem when it is rendering a graphic and the hooks are in the OS
kernel, it can get control. GDI has to look into the grapic coding and interpret it to view
it. It is the rendering engine that can be exploited.
yEnc is a communication protocol and does NOT have hooks in the OS. It is also not MS
Windows specific. You could implement it into Unix/Linux email or news clients or any other
Operating System email or news clients.
N
NobodyMan
Ask elsewhere. Yenc has nothing to do with the OS.I have been resisting this compression. Are there any security concerns?
What's the easiest way to read it?
Thanks,
Fred