On Wed, 2020-01-01 at 10:29 +0100, Elmar Stellnberger wrote:
>Up to now I did not see any notable effort to support malware reverse
> engineering under Linux. The only program I knew was boomerang for
> decompiling malware but it seems to be unsupported since long. I would
> really be in
> Some of its checks look inherently dangerous, e.g. the bash -n check for
> shell syntax.
Why would bash -n be dangerous?
signature.asc
Description: OpenPGP digital signature
* Paul Wise:
> On Wed, Jan 1, 2020 at 1:00 PM Florian Weimer wrote:
>
>> Doesn't lintian on ftp-master use disposable VMs?
>
> No mention of qemu/kvm in dak.git nor any qemu processes running on
> ftp-master.d.o, so I don't think so.
Uh-oh.
>> Some of its checks look inherently dangerous, e.g.
* Daniel Reichelt:
>> Some of its checks look inherently dangerous, e.g. the bash -n
>> check for shell syntax.
>
> Why would bash -n be dangerous?
In the past, the bash parser was not very successful at inhibiting
command execution. I doubt that this has changed, although some
corner cases
On Wed, Jan 1, 2020 at 1:00 PM Florian Weimer wrote:
> Doesn't lintian on ftp-master use disposable VMs?
No mention of qemu/kvm in dak.git nor any qemu processes running on
ftp-master.d.o, so I don't think so.
> Some of its checks look inherently dangerous, e.g. the bash -n check for
> shell
* Paul Wise:
> On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote:
>
>> BFD and binutils have not been designed to process untrusted data.
>> Usually, this does not matter at all. For example, no security
>> boundary is crossed when linking object files that have been just been
>> compiled.
>
On 01/01/20 10:29, Elmar Stellnberger wrote:
Up to now I did not see any notable effort to support malware reverse
engineering under Linux. The only program I knew was boomerang for
decompiling malware but it seems to be unsupported since long.
probably here you can find some useful:
Am 01.01.20 um 10:48 schrieb PJ:
Maybe ultimately one needs monitors and diff-machines built in hardware
(and more or less by oneself).
If compilers can be subverted, so can assemblers.
It would be really worthwhile to have a decompiler!
It is not assemblers that are subverted but machine
Am 01.01.20 um 10:29 schrieb Elmar Stellnberger:
> Am 01.01.20 um 03:14 schrieb Paul Wise:
>> On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote:
>>
>>> BFD and binutils have not been designed to process untrusted data.
>>> Usually, this does not matter at all. For example, no security
>>>
Am 01.01.20 um 03:14 schrieb Paul Wise:
On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote:
BFD and binutils have not been designed to process untrusted data.
Usually, this does not matter at all. For example, no security
boundary is crossed when linking object files that have been just
On Tue, Dec 31, 2019 at 9:47 AM Florian Weimer wrote:
> BFD and binutils have not been designed to process untrusted data.
> Usually, this does not matter at all. For example, no security
> boundary is crossed when linking object files that have been just been
> compiled.
There are definitely
* Andreas:
> there is no security support for binutils in debian stable
> (buster). Given the importance of binutils this seems to me to be a real
> problem.
BFD and binutils have not been designed to process untrusted data.
Usually, this does not matter at all. For example, no security
Hi,
there is no security support for binutils in debian stable
(buster). Given the importance of binutils this seems to me to be a real
problem.
I searched quite some time for reasons for this strange fact, but while
I found many references to the fact, I didn't find any explanation for
the
13 matches
Mail list logo
